Map business dependencies, not just interfaces
An ERP estate usually contains APIs, file transfers, database reads, scheduled jobs, message queues, and manual imports. An endpoint inventory alone misses the operational chain. A successful order request may still depend on credit checks, inventory reservation, shipping instructions, and financial posting. If one step is delayed, the caller may report success while the transaction remains incomplete. Treat the end-to-end business flow, rather than an individual program, as the unit of migration.
For each flow, record its direction, trigger, owner, system of record, acceptable delay, failure impact, replay method, and audit requirements. Then classify it by operational criticality. This exercise often exposes risky dependencies such as direct writes to ERP tables, interfaces with no accountable owner, and recovery procedures known only to one operator.
- Must remain live: Core order, shipping, or production flows need a tested alternate route and continuous monitoring during cutover.
- May be delayed: Notifications, reports, and analytical feeds can enter a durable queue and be replayed after the new ERP stabilizes.
- May be paused: Low-frequency processes with reliable manual controls can use a defined outage window and catch-up procedure.
- Should be retired: Unvalidated database access and integrations with poor traceability should not be reproduced unchanged.
Put a stable integration boundary around both ERPs
If every surrounding application must understand the fields, status codes, and validation rules of both ERPs, migration complexity spreads across the estate. Instead, expose versioned API, event, or file contracts and use adapters to translate between those contracts and each ERP. Consumers remain attached to a stable boundary, while routing can direct a business flow to the legacy ERP, the new ERP, or a holding queue.
A shared contract should not become an enormous canonical model. Standardize only durable concepts such as order identity, customer, item, quantity, and processing state. Keep ERP-specific accounting fields and custom workflows inside dedicated adapters. Use synchronous APIs when the caller needs an immediate validation result; use events or queues when temporary delay is acceptable. Consider change data capture only when the legacy platform cannot emit events and its data owner permits the additional database coupling.
- Version contracts: Add fields compatibly and create a new version for breaking changes, so consumers do not all migrate on one date.
- Make writes idempotent: Use a business key or event identifier to prevent retries from duplicating orders, shipments, or journal entries.
- Preserve replay data: Retain the original message, result, and failure reason so corrected transactions can be replayed safely.
- Block direct table writes: Updates should pass through controlled interfaces that enforce validation, authorization, and audit rules.
Validate business outcomes during parallel running
Before cutover, production-like traffic can be mirrored to the new ERP in shadow mode, with external side effects such as shipments, customer messages, and financial postings disabled. Avoid comparing every field literally: the platforms may use different identifiers, tax allocation rules, or status lifecycles. Compare business invariants instead. Confirm that accepted orders contain valid lines, reservations match demand, postings balance, and rejected transactions remain traceable to their source.
Dual writing appears convenient but creates a distributed transaction: one ERP can accept a write while the other fails. Unless both platforms genuinely need to act as the system of record, prefer a single write authority and propagate changes through events, controlled batches, or change capture. Store source identifiers, timestamps, processing states, and synchronization watermarks. Reconcile counts, amounts, and lifecycle states regularly. For irreversible transactions, the rollback plan must specify compensating entries rather than assume that restoring a database will undo real-world activity.
Turn cutover into small, stoppable steps
Move by business capability rather than switching every connection at once. A sequence might begin with read-only queries, continue with master-data synchronization, and leave order or finance writes until later. Each wave needs entry criteria, an observation window, stop conditions, and a tested recovery route. Freeze unnecessary contract and master-data changes beforehand, then run contract tests, historical replays, capacity tests, and failure drills. Keeping the old server online is not a rollback plan unless it can also receive current data and resume processing.
Operational dashboards should show successes and failures, queue age, processing latency, duplicates, synchronization watermarks, and reconciliation differences. Every alert needs an owner. Routing switches, shutdown steps, catch-up scripts, and manual fallback procedures should be rehearsed before the migration window. Clear evidence and predetermined controls let the team continue, pause, or reverse a wave without improvising under pressure. When an integration team is involved, its most valuable contribution is this verifiable migration control plane, not merely reconnecting the same interfaces.