Application Migration

Duration: 2-4 weeks

• Audit an application/application portfolio (app technology stack, when an app was created, its availability, scalability and fault tolerance requirements, etc.), the server environment.
• Assess application security and compliance risks, clarify app user access management, and determine app migration readiness.
• Prioritize applications or app parts to be migrated based on their dependencies, availability requirements and business criticality level.
• (for business software) Review key business processes supported by an application under migration, identify a business owner of each process. Develop business process maps to make sure that all the necessary functionality was taken into account for migration.

Best practice #1: For business app migration, ScienceSoft considers customer-facing apps and apps with fewer dependencies as the first choice for migration.

Best practice #2: To reduce migration budget, time and risks, ScienceSoft usually migrates interdependent applications together. We create ‘migration groups’ basing on the analysis of the applications’ business and technical requirements, including dependency details.

Duration: 1-2 months

• Select the target environment (cloud, on-premises, hybrid).
• Select the most efficient migration approach (e.g., for cloud migration, one out of 6 Rs – rehost, replatform, refactor, retain, repurchase (for enterprise apps), retire – or a combination of several approaches).
• (for cloud migration) Choose a cloud platform and decide on fitting cloud services.

• (except for purchased enterprise apps) Taking into account the technology stack, conduct code audit to identify application areas that require modifications and adjustments for the target platform; decide on the application code conversion strategy.
• Gain a 360-degree view of dependencies:
  • data flows and their dependencies;
  • containers and microservices;
  • hardware and software load balancing;
• Create a detailed migration plan with the required efforts and schedule the exact steps to get to the new environment.

Duration: depends on the scope and depth of changes

Unless it’s simple lift-and-shift migration, there’s often a need to adjust application code and design for the new environment (especially, for app parts that are too risky and expensive to migrate, e.g., for legacy apps). At this stage, software engineers change and update application architecture design and code to take advantage of cloud services and general cloud elasticity and scalability, in case of cloud migration.

Best practice: At ScienceSoft, we mostly use code conversion tools and, if required, make targeted manual adjustments to the results of automated conversion.

Duration: 3–10 weeks

For complex and data-intensive applications, the migration team works out a strategy and chooses tools to migrate the app data. The team:

• Performs a data quality check to make sure that data is valid and has no duplicates.
• Creates scripts to perform data extracting, cleaning and loading to the target environment.
• Builds a tool or creates a script to automate data migration (automation is optional and depends on the data availability requirements).
• Performs and validates trial data migration.
• Executes massive data migration and tests the results.

Duration: 2-4 weeks

To minimize possible migration risks, the migration team can execute pilot migration that doesn’t affect the real production environment. To do that, the team:

• Sets up a beta environment.
• Tests and fine-tunes the functionality of the migrated application using test data and test database.
• Tests scalability, load balancing, and capacity of the app and its infrastructure after loading production-equivalent test data.
• Assesses the results of pilot migration, finalizes the future app architecture.
• Develops and applies solutions for problems identified during mock migration.

Duration: 3-6 weeks

Actual application migration is structurally much the same as mock migration. The team:

• Schedules and communicates applications’ downtime.
• Sets up a new production environment.
• Sets up DevOps tools and processes.
• Migrates the application(s).
• Migrates APIs and dependent apps (optionally).
• Documents app changes, updates configurations.
• Validates that migration activities haven’t affected application functionality and performance.
• Sets up monitoring tools.

Best practice: To minimize operational downtimes, ScienceSoft splits the cloud migration process into clear, manageable parts and are always ready to roll back. Also, we often and widely employ automated tests to check the changes promptly, frequently and comprehensively.

Duration: 2-4 weeks

The team removes an old application or unnecessary software parts of the migrated application, cancels relevant vendor contracts (if any), shuts down related application and its infrastructure monitoring tools.

Best practice: ScienceSoft recommends leaving the source environment for 2-4 weeks after migration in case issues occur in the new environment (especially if any code conversion took place). After that, we disable the unnecessary application/applications but don’t delete them for another 6-18 months in case any significant problems arise.

The team sets up monitoring tools to keep track of logs, performance, response time, load, etc., of the application/applications operating in the new environment. Also, the team can develop and implement an operating cost optimization strategy for the migrated application/applications.