Phases of a software migration project
This is the third part of a series on migration — you'll find the starting point here.
Once the decision to migrate has been made, the implementation can be broken down into the phases below. Each one requires careful planning, analysis and execution. None of the items below — and the list is not exhaustive — is trivial; most need to be substantiated further:
Build an understanding of the source (legacy) system: Before a migration begins, it's important to develop a comprehensive understanding of the existing legacy system. That includes capturing the system architecture, data structures, interfaces and dependencies from existing documentation and/or reverse engineering. It also means analysing in detail the problems that led to the decision to replace the old system.
Define the core strategy:
Is standard, off-the-shelf software an option (for non-core domains)?
In-house or external development: the decision whether the migration is carried out internally or externally — for example by a service provider.
System environment: How should the new application fit into the organisation's application landscape, and which tech stack should be used?
Concept and design: What team composition makes sense for the design phase? Should a service provider be brought in?
Deadlines: Which deadlines absolutely have to be met — for example because licences or support for the existing solution are running out, or new legal requirements are coming into force?
Cost/benefit analysis: Evaluating the costs and benefits associated with the migration.
Risk analysis: Identifying and assessing potential risks tied to the migration.
How is the new solution activated?: Defining the concrete approach to the migration — for example step-by-step or big-bang.
Clarify side effects: Do other systems need to be adapted once the migration is complete (e.g. because of changed data formats, encodings, etc.)?
Training: Does the team carrying out the migration need additional training in specific areas or tools?
Detailed design:
Application: Check the reusability of existing components, choose a new tech stack, and develop a future-proof architecture concept — avoiding unnecessary complexity.
Strategy: Is conversion or encapsulation of (parts of) the existing legacy system an option (see "Considerations before a migration project")?
UI: Is the user interface part of the application directly, or a separate piece (e.g. an app or single-page application)? What new requirements apply to the UI — accessibility, for example?
Data: Is a data migration needed, and how should it be done?
System environments: Provisioning of development, test, optionally acceptance, and the final production environment.
Interfaces: Which external interfaces are relevant to the application? Are they directly available, or do they have to be emulated for development and testing? Does special hardware have to be integrated, and how?
Security: Are there special security requirements — for example specific encryption methods?
Cross-cutting functionality: How will logging, system monitoring and the like be implemented?
Scaling: Defining the performance and scaling requirements. How will scaling work — vertically or horizontally? Does the chosen architecture support horizontal scaling?
PoC: Identifying the necessary "proof of concept" solutions and whether a pilot system is needed.
Project management: Defining the necessary resources, budget, controlling, timeline and project duration. Choosing the development methodology (e.g. Scrum). Sourcing offers if external partners are to be involved.
Deployment: How can a fast, efficient (iterative) deployment into the target environment be achieved? Which CI/CD methods are appropriate, and which tools are needed?
Team composition: Is one team enough? Who takes which role on the team (development, DevOps, project lead, …)? Specific process models like Scrum may require additional roles (e.g. Scrum Master).
Partners: Which external partners need to be involved, and how is communication with them organised?
Communication: How does communication work within the team and between the team and users? Which tools are used (bug tracker, productivity tools like Slack or Teams)? What does the chosen methodology require (e.g. Daily Scrum)?
Documentation: How is the project documented (for developers and users)?
Testing: Which testing approaches are used (automated code tests, UI tests, integration tests, …)? Depending on the methodology (think Test-Driven Development), additional resources may need to be planned in.
Acceptance: Who is responsible for accepting the system, and which criteria have to be met for acceptance to succeed?
Compliance: Which guidelines have to be observed (accessibility, GDPR, …) and who checks compliance?
Change management: How are changes to requirements during development handled?
Data protection: Can development testing be done against real data, or are we dealing with personal data that needs to be anonymised first?
Build the target system:
Creating proof-of-concept solutions for critical parts of the application — especially around hardware and external software interfaces.
Development and configuration of the target system based on the requirements and concepts produced in the design phase.
Iteratively releasing test systems (that have already passed developer tests) to involve users early.
Preparing tools to support the migration / cut-over process — for example for data migration.
Creating the scripts needed for iterative deployment of the application (e.g. GitHub Actions).
Ongoing controlling to make sure development is staying on plan.
Project documentation.
Final testing:
Comprehensive tests, including integration and acceptance tests, to confirm that the target system delivers the expected functionality.
Are the requirements for performance and scalability met?
Verification against all compliance requirements.
Does the documentation match the requirements?
Carrying out security checks and penetration tests where required.
Operations, monitoring and support:
Ongoing system monitoring so deviations can be addressed immediately — ideally before they affect availability for users.
User support.
What matters throughout is a methodical approach with minimal disruption to operational use.
Part 4: Software migration in practice: .NET -> .NET Core
We're happy to help with this complex topic
If you're planning a migration and would like a sparring partner, reach out via our contact page — we'll come back to you within one working day.