Planning a Legacy System Modernisation: Data, Workflows, and Rollout
On this page
Start modernisation with the operational constraint: an order needs several manual corrections, a report arrives too late, or an unsupported component prevents further changes. Identify the affected workflow and what must improve, then decide which parts to retain, extend, connect or replace.
Map the work before choosing the replacement
Identify the workflows, users, scheduled jobs, integrations, shared data, and reports the business depends on. Include informal processes: spreadsheet exports, manual corrections, and work performed outside the application.
For each dependency, record an owner and an example of how it is used. An apparently small reporting tool may be critical to a daily decision; risk should be judged by business impact, not by the component's name.
Decide what to retain, connect, or change
Compare options against the required outcome:
- Keep a component that meets the need and has acceptable operational constraints.
- Extend an existing capability where its structure and maintainability permit it.
- Integrate a new module when the boundary and data responsibilities are clear.
- Replace a component when the required behaviour cannot be supported reasonably by the existing approach.
A staged replacement reduces the scope of each change but creates a period when both systems must be supported. Include synchronisation, reconciliation and support for that period in the budget.
Separate migration from synchronisation
Migration moves agreed records and history. Synchronisation exchanges selected changes over time. List the data required for each, then agree:
- The source of truth for each record or field.
- Mapping, transformations, and required history.
- The exchange direction and update schedule.
- Stable identifiers and duplicate handling.
- Conflict rules, failure visibility, and retry behaviour.
- Reconciliation checks and ownership of corrections.
Track incomplete exchanges across every connected system and assign responsibility for restoring consistent records.
Rehearse with records that can reveal a failure
A migration sample should include the exceptions that are easy to miss in clean demonstration data: a customer with two addresses, a cancelled order, an amended invoice, a missing identifier, and an attachment linked to a historical transaction. Use non-production or appropriately protected data in the rehearsal environment.
For an example order migration, a reconciliation sheet could record:
- The source order identifier and the corresponding new identifier.
- The customer, line items, quantities, currency, and agreed status mapping.
- Counts and totals before and after transformation, with documented exclusions.
- References to related documents and the permissions needed to open them.
- Rejected records, the reason for rejection, and the person who resolves each issue.
Check record relationships as well as totals. An unchanged second import should follow the agreed duplicate rules; an amended source record should follow the update rules.
Plan and verify the data migration
Use the worksheet to record the migration scope, check repeated imports and document the decision to launch or delay.
- Record mapping and relationship checks
- Duplicate, amendment and permission scenarios
- Exception owners, launch conditions and recovery checks
Editable text file (.txt)
Fill it in locally using a text editor or your own document. Share a non-confidential summary when you contact us.
Use a trial import to decide what needs fixing
In this fictional sample, the agreed scope contains open orders only. Cancelled M-103 remains in the legacy history. Customer mappings C1 and C3 exist, while required customer C2 is missing. Amounts use USD with no transformation.
Scroll the table horizontally to compare all columns.
| Source order | Customer reference | Value (USD) | First import result |
|---|---|---|---|
| M-101 | C1 | $1,000 | Imported |
| M-102 | C2 | $600 | Missing customer mapping |
| M-103 | C1 | $400 | Cancelled; excluded by scope |
| M-104 | C3 | $200 | Imported |
Required source value: $1,800. First imported value: $1,200. After C2 is mapped and the import is repeated: 3 orders, $1,800. Data reconciliation: Passed.
The first run transfers M-101 and M-104 but rejects M-102. The source population is three required orders worth $1,800; the target contains two worth $1,200. Excluded M-103 is recorded separately and must not be used to explain away the rejected open order.
Exception log entry: M-102 / missing C2 mapping / $600 / blocking. The client data owner verifies C2's stable identifier and approves the mapping. The migration engineer corrects the mapping, repeats the import and attaches the resulting record and relationship checks. The operations owner reviews the evidence.
After that correction, the example contains three orders worth $1,800 and M-102 points to C2. Repeating the same import leaves three orders, not six. The displayed totals come from the rehearsal model; automated tests check the failure, repair and replay.
Before correction: hold the transition. A required open order is missing. After correction: this data check passes. Full launch also requires checks of permissions, documents and critical workflows, plus an agreed procedure for final updates, recovery and support.
A real project can accept a documented exclusion when its business owner understands the consequence. It should not convert an unresolved rejection into an exclusion merely to obtain a passing percentage. The acceptance threshold is an agreed business rule; this sample requires all three in-scope orders and their relationships to match.
For daily operation after migration, use the CRM–ERP integration guide to define ongoing changes and retries. Use the phased ERP rollout guide to decide which team takes responsibility first and what evidence allows expansion.
Preserve the meaning of reports
Inventory the reports used for management and operations. Record sources, formulas, periods, filters, and permissions. Moving the data does not automatically preserve the meaning of a metric.
Compare results for agreed sample periods. Explain any intended differences before users switch to the new report. Show the update time so a delayed source is not mistaken for current information.
Use the reporting integration guide to define source ownership, reporting cutoffs, and the checks needed when several systems contribute to one result.
Choose the first workflow to replace
A candidate release needs a clear business outcome, known dependencies, an available owner, and a way to validate results. Evaluate its value and operational impact together. A small but heavily connected component may be harder to introduce than a larger, more independent workflow.
Define acceptance using actual scenarios, including exceptions and access rules. Make the work required in both old and new systems visible during coexistence.
Plan cutover and recovery
Agree how new writes are handled, which records need final reconciliation, who decides whether to proceed, and how users are informed. A rollback plan must account for data created after the switch; routing requests back does not automatically reverse new records or external actions.
Test the transition steps and recovery assumptions in an appropriate environment. Determine any maintenance window from the actual constraints rather than promising a universal zero-downtime launch.
At the launch review, the decision owner checks the agreed evidence: critical workflows pass, records reconcile, unresolved exceptions have an accepted treatment, and support can detect and resolve failures. If a condition fails, delay the launch, reduce its scope or follow the rehearsed recovery procedure.
Separate assessment from taking responsibility
An initial review does not transfer incident or production responsibility. For an existing application, identify repository and deployment access, account owners, dependencies, known incidents and recovery evidence. Scope assessment, stabilisation and ongoing support separately, and record when responsibility changes. Use the application support enquiry when your goal is a provider handover.
Bring the transition into the budget
Assessment, interfaces, cleanup, migration rehearsals, reconciliation, documentation, and user preparation need a place in the scope. Support during rollout and ongoing operation should be defined separately where appropriate.
Explore our modernisation service, data and reporting scope in custom ERP, and pricing models. To start, tell us which system supports your business today.
