Go live

Go-live is the last step in the Web migration process for the application to go live successfully without serious problems, Appeon strongly recommends you have done the following tasks in all related areas to reduce the likelihood of go-live problems:

Unsupported Features:

  • Ensure there are no unsupported features in the application. At a minimum, the UFA report should not list any unsupported features.

Performance fine-tune:

Functionality:

  • Verify all application functionality is working properly. Functionality should be tested on all the browser version(s) that will be supported. For example, IE 7 32-bit, IE 8 32-bit, IE 8 64-bit etc. Please note: if the application uses third-party DLLs/OCXs/OLEs then 64-bit version of those files need to be packaged in order for the Web application to run correctly on 64-bit browsers.

Hardware/Software configuration:

  • Select appropriate hardware to install Appeon Server. Appeon can give some suggestions based on the # of users, but in general use the most powerful server that customer has budget for.

  • Configure IIS settings properly. Appeon can give some suggestions based on the # of users and type of hardware that will be used.

  • Understand the Web browser and system configuration/settings requirements and ensure that all users are aware of these requirements and that their browser settings are correct. If third-party DLLs/OCXs/OLEs are used the Web browser and system settings will need to be significantly changed, so if possible for ease of deployment and user satisfaction it is most preferred to avoid any third-party DLLs/OCXs/OLEs.

Performance and scalability:

  • Verify the application response time over "realistic" network connection. What we mean by realistic is to use the same network connection (bandwidth and latency) that the average user will use. Test all application functionality to ensure that the application performs well.

  • Verify the application scalability. There are two ways to do this. One is to use a scalability testing tool such as LoadRunner. The other option (and more preferred) would be to do a partial beta test. Essentially, get a group of users together to simultaneously use the system to see if any problems. The problems you are looking for is significant degradation in performance when multiple users on the system and/or system instability (e.g. IIS or database stops responding or crashes).

Beta test and controlled roll-out:

  • Perform a beta test. Roll out the application to a smaller group of real users to see if any major problems. Expectations should be set with the users that this is a "beta" not a "live" situation. The users should be prepared that problems are likely to happen and they should be able to tolerate downtime of the system for several days or longer to correct any problems that are found.

  • Perform a controlled roll-out. After the beta test has run for sufficient time with no major problems then increase the # of users.

Now go live! After the controlled-rollout has run for sufficient time with no major problems then go live.