Legacy System Migration Checklist: Plan, Test, Cut Over, and Retire

A legacy system migration succeeds when the business can continue operating, users can complete critical work, data is trusted, interfaces behave predictably, support teams know what to do, and the old environment is retired deliberately. Deploying a new application is only one event inside that outcome.

This checklist is designed for application, platform, and data migration. Adapt the depth to risk. A small internal tool does not need the same governance as an order, finance, clinical, or customer-facing system, but both need clear ownership and acceptance.

If the organisation has not yet chosen a disposition, begin with legacy system modernization services or the modernization strategies comparison. Migration planning should follow a defensible decision, not create one accidentally.

1. Confirm the Migration Outcome

• State the business problem and capability the migration supports.
• Identify the executive, business, technical, data, and operational owners.
• Define users, locations, operating hours, and critical journeys.
• Record scope, exclusions, assumptions, constraints, and deadlines.
• Define success measures and business acceptance.
• Identify regulatory, contractual, retention, and continuity requirements.
• Confirm whether the old system will retire, remain read-only, or coexist.

Avoid a goal such as "move to cloud" without a business and operating outcome. The target may reduce infrastructure risk but leave change lead time or data quality untouched.

2. Inventory the Current Environment

• Application versions, modules, customisations, and scheduled jobs
• Infrastructure, networks, storage, and environments
• Databases, files, attachments, archives, and reports
• Interfaces, APIs, queues, shared files, and direct database access
• Identity, roles, service accounts, and privileged access
• Monitoring, alerts, backups, recovery, and incident procedures
• Vendors, licences, certificates, domains, and dependencies
• Source repositories, build tools, deployment, and configuration
• Manual workarounds and spreadsheet processes

Validate the inventory with operators and logs. Diagrams often miss manual transfers and small scripts that carry critical information.

3. Map Dependencies

For every dependency, record owner, purpose, direction, schedule, protocol, authentication, data, volume, failure behaviour, monitoring, and consumers. Mark dependencies that cannot tolerate interruption or replay.

Trace important business journeys end to end. A customer request may cross website, CRM, integration, legacy application, payment, notifications, and reporting. The migration boundary must account for the whole journey even if only one system changes.

Separate proven dependencies from assumptions. Assign discovery actions for unknowns before the cutover plan is approved.

4. Define the Target and Transition State

• Target application and infrastructure design
• System-of-record decisions for each data domain
• Identity, access, secrets, and service accounts
• Interface contracts and error handling
• Monitoring, logging, alerting, and support ownership
• Backup, recovery objectives, and restoration evidence
• Deployment, configuration, and environment management
• Data migration, archive, and reconciliation
• Temporary synchronisation or parallel-running design
• Conditions that allow transition components to retire

Review the target against internal skills. Name who will operate each component after the project team leaves.

5. Prepare the Data Migration

• Identify source tables, files, documents, and historical archives.
• Profile completeness, duplicates, invalid values, relationships, encodings, and volume.
• Assign business owners for mapping and cleanup rules.
• Define identifiers and how records match across systems.
• Decide what migrates, transforms, archives, or does not move.
• Document retention, deletion, privacy, and audit requirements.
• Build repeatable extraction, transformation, and load steps.
• Protect source evidence and migration versions.
• Define record counts, totals, samples, and business reconciliation.
• Plan exception handling and manual correction.

Run more than one rehearsal. Record duration and defects so the cutover schedule reflects evidence.

6. Prepare Interfaces

• Confirm every producer and consumer.
• Decide whether each interface remains, changes, or retires.
• Define message or file contracts and versioning.
• Test authentication, certificates, credentials, and network paths.
• Define timeouts, retries, duplicate handling, and idempotency.
• Add monitoring and alerts that name an owner.
• Prepare replay or reconciliation where messages can be delayed.
• Test downstream reports and manual processes.

Use API integration support where a governed interface is part of the target, but keep business ownership and failure handling explicit.

7. Build Representative Environments

Development and test environments should reproduce the important behaviour, integrations, permissions, configuration, and data shapes of production without exposing live sensitive data carelessly.

• Control environment configuration and secrets.
• Use representative volumes for performance and migration tests.
• Verify network, identity, certificates, and external dependencies.
• Establish deployment and rollback procedures.
• Record environment differences and accepted limitations.
• Protect staging from public indexing where web applications are involved.

An unrealistic test environment creates false confidence.

8. Define the Test Strategy

Cover more than functional scenarios:

• Critical end-to-end user journeys
• Business rules and calculations
• Roles, permissions, and segregation
• Data migration and reconciliation
• Interfaces and failure states
• Performance, volume, and batch windows
• Resilience, recovery, backup, and restoration
• Monitoring, alerts, and support workflows
• Reports, exports, audit, and archive access
• Accessibility and device coverage where relevant
• Operational tasks and administration
• User acceptance and training readiness

Map tests to acceptance criteria and owners. Record defects by consequence and release decision, not only severity labels.

9. Plan Business Change

• Identify affected roles and process changes.
• Confirm new ownership and approval paths.
• Prepare training with realistic tasks.
• Update procedures, controls, and support routes.
• Communicate timing, downtime, and expected changes.
• Provide a route for questions and adoption feedback.
• Plan additional support during early operation.

User acceptance is not a final demonstration. Involve operators while workflows and exception paths can still change.

10. Build the Cutover Runbook

The runbook should be executable by named people. Include sequence, start conditions, owners, expected duration, dependencies, communication, evidence, and stop criteria for every step.

Typical elements include:

1. Confirm go/no-go participants and channels.
2. Verify backups, target health, credentials, and monitoring.
3. Apply change freeze or transaction controls.
4. Complete final extract and migration.
5. Reconcile data and critical totals.
6. Switch interfaces, routing, or user access.
7. Run technical smoke tests.
8. Run business journey checks.
9. Confirm monitoring and support coverage.
10. Approve release or activate rollback.
11. Communicate status to users and stakeholders.

Use absolute times and time zones. Avoid instructions such as "after the database is ready" without an owner and acceptance signal.

11. Define Rollback and Recovery

Rollback is not simply redeploying old code. Define what happens to transactions and data created after cutover. Identify the point at which reverting becomes unsafe or requires reconciliation.

• Conditions that trigger stop, rollback, or contingency
• Decision authority and response time
• Technical reversal steps
• Data reversal or replay
• Interface restoration
• User communication
• Validation after rollback
• Evidence preservation and incident review

Rehearse high-risk recovery steps. A document that nobody has executed is an assumption.

12. Hold a Real Go/No-Go Review

Review evidence, not optimism:

• Critical tests passed and material defects accepted by owners
• Migration rehearsals completed within the window
• Data reconciliation approved
• Interfaces and downstream consumers validated
• Operational monitoring, backup, and recovery ready
• Support and escalation staffed
• Training and communication complete
• Cutover and rollback runbooks reviewed
• Required access and vendors available
• Business owners understand known limitations

Record the decision, conditions, and owners. Do not allow calendar pressure to become the acceptance criterion.

13. Monitor Early Life

Monitor technical and business signals after release:

• Errors, latency, capacity, failed jobs, and interface queues
• Reconciliation differences and duplicate records
• User completion of critical journeys
• Support contacts and workarounds
• Reports and downstream processing
• Access and permission issues
• Cost and resource usage where relevant

Run frequent operational reviews during the stabilisation period. Separate defects from enhancement requests so the team protects the release without losing useful feedback.

14. Decommission the Legacy Environment

Do not leave decommissioning as an unfunded future task.

• Confirm business and data-owner approval.
• Verify archive and historical access.
• Remove or redirect interfaces.
• Disable user and service accounts appropriately.
• End licences, hosting, support, and monitoring.
• Retain required logs, records, and evidence.
• Dispose of infrastructure and data according to policy.
• Update inventories, diagrams, runbooks, and support ownership.
• Record savings and risk removed.

Keep the old environment read-only only when there is a justified need, named owner, access control, cost, and retirement condition.

15. Complete Operational Handover

Transfer repositories, deployment, configuration, environments, credentials ownership, monitoring, alerts, backup, recovery, vendor contacts, licences, architecture, data definitions, interface contracts, support runbooks, known limitations, and backlog.

Confirm that the operational team can deploy, diagnose, restore, escalate, and manage access. A handover meeting is not enough; ask the team to demonstrate critical procedures.

Migration Governance

Keep decisions visible. A migration decision log should record context, options, rationale, owner, date, consequence, and review condition. Track assumptions separately and close them with evidence.

Connect the migration to the technology roadmap so shared data, integration, identity, cloud, and operating-model dependencies stay visible across projects.

Common Migration Failures

• Approving a date before dependency and data discovery
• Testing happy paths but not failures and exceptions
• Treating data reconciliation as record counts only
• Missing reports and manual downstream consumers
• Changing the application, infrastructure, data, and all interfaces at once
• Having a rollback plan that ignores new transactions
• Training users after workflow decisions are fixed
• Running old and new systems without clear ownership
• Forgetting licences, access, archives, and decommissioning