At a high level, the following activities are involved in a typical redevelopment / migration project:

1. Requirement Analysis: The “Requirement Analysis” phase is aimed at understandin the specifics regarding the Source and Target environment. Since the effort required and the strategy to be adopted depends largely on these details, the specific details are determined with high level of accuracy. This stage encompasses removing obsolete code, identifying missing sources, identifying interfaces, building the inventory of active code and possibly breaking up the web application in logical packets for conversion. This helps in refining the project plan with detailed scope of work, data conversion and synchronization needs and level and depth of testing required. A significant amount of activity is performed onsite with feedback from customer, gathering technical and user documents and also collecting the performance related data of current system.

2. Installation of Source/Target Environment: All the required software components and tools are installed in the Source environment and then application will be installed on the Source platform.The Target machine will be setup with the target environment as per the requirement. The environment will be setup with the require Hardware, OS Version, Language Upgrades, Core Software Upgrades, Modules Upgrades etc. Detailed analysis will be done to study the differences between the source and the target environment and application features and a GAP analysis document is prepared.

3. Build and Test in Target Environment: For reengineering and redevelopment, an application is built from ground up with all the listed functionality. While for the upgrade and platform conversion projects the source code is converted (patches applied, modules upgraded, bugs fixed, etc) and will be loaded on the TARGET environment. It is expected that errors will be thrown in this process. The quantity and nature of errors will largely depend on the differences between the SOURCE and TARGET environment, version differences etc. After studying the nature of errors, corrective actions are taken. Unit testing of converted code assumes basic testing to see that converted code complies properly and will do what it was doing.

4. Integration Testing: Integration test involves testing of third party applications and external interfaces with the core site. The web application is first tested and made bug free. Once done, we proceed for integration testing on the target environment. Testing will be based on the test cases and test data provided by client. If the client needs the functionality test, product manual will be studied for functionality and test cases will be prepared on the basis of the functionality described in the product manual. These test cases will then be submitted to the customer for approval. On approval these test cases will form the acceptance criteria for the migration project. Integration testing involves running the programs on the target machine with converted data. This also involves sending test files to upstream/downstream systems and external partners on their test environment to ensure the equivalent functioning of new system compared to old.

5. System/Parallel Testing: This activity is general performed on Drupal upgrade projects. Once the integration testing is done, it is assumed that the software functions properly on the target environment on a newer software version. At this moment, parallel testing is done by running same test cases on source and target environments and results are compared. In this stage the performance of target system is also compared to source system to ensure that the converted system meets the performance benchmarks.

6. UAT: Once the parallel testing is done, the system is handed over to the client business and technical to test the functionality of the target system. This will give the users and technical staff confidence that the target system is exact equivalent of the source system with improved functionality (if in scope). The user acceptance results in a sign off of the test results and the system is ready to be moved to production.

7. Move to Production: Once the UAT is done and if the customer is comfortable with the acceptance testing results the system can be rolled over in production. Before the production rollover the entry in existing source system is halted. Data is converted into to the new data model and fed into the new system.

8. Documentation: Sufficient documentation will have to be provided along with the application.

• The system document, installation guide and user manual will be modified to reflect the changes.