Integration migration is rarely safe as a big bang. Producers, consumers, batch schedules, and data rules cannot always move together. Phased migration limits blast radius but adds dual-run and reconciliation cost. Waves should follow dependencies and proof capability, not merely the easiest applications.
Big bang concentrates risk; dual-run extends cost
A simultaneous move shortens the period of two systems, but failure affects many processes and root cause becomes harder to isolate. Phases create learning space while charging for duplicate infrastructure, temporary mappings, two support paths, and reconciliation. Without a boundary, “temporary” can last for years.
Unknown dependencies often create the largest cost. An invoice flow may feed accounting, CRM, reports, and a tax vendor on different schedules. Moving the producer without identifying consumers creates split-brain authority. Discovery and source-of-truth decisions belong in the migration budget.
Group waves by dependency and risk
| Candidate | Suitable wave | Reason |
|---|---|---|
| Low volume, clear owner, test data available | Pilot | Exercises tooling and runbooks with limited blast radius |
| Similar to pilot, known dependencies | Early scale-out | Validates reuse without major new variation |
| Critical, many consumers, complex reconciliation | After foundations stabilize | Needs mature recovery and observability evidence |
| No owner or unclear contract | Hold | Risk cannot be accepted until governance improves |
Create a dependency graph covering source, destination, schedule, schema, credentials, agents, network, owners, and business periods. Do not place all critical integrations in one wave. Equally, do not migrate only quick wins forever; define when capability is sufficient for higher-value candidates.
Run each wave as a controlled experiment
- Baseline and entry review.
Record volume, errors, latency, totals, dependencies, and owners. Entry criteria verify schema, tests, rollback, and capacity.
- Bounded shadow or dual-run.
Run the new path without making it authoritative, then compare counts, value, order, and duplicates. Prevent actions from doubling business effects.
- Cut over with stop conditions.
Define time, incident commander, rollback threshold, communication, and freeze. Only one path may be the authoritative writer.
- Stabilize and retire.
Observe a relevant business cycle, resolve differences, revoke the old path, and feed lessons into the next wave.
Rollback must address data, not only applications. Define what happens to messages received after cutover, how replay avoids duplicates, and who approves correction. If both systems write during rollback, reconciliation and source-of-truth rules must be explicit.
Use a reconciliation gate
- Record counts, business value, duplicates, and missing items are compared.
- Failure paths, agent outage, destination rejection, and recovery are tested.
- Cutover and rollback have owners and time limits.
- Dual-run has funding and a shutdown date.
- Schema drift and dependency changes are frozen or controlled.
- The next wave waits for exit criteria rather than a calendar date.
Track defects per wave, reconciliation differences, dual-run duration, rollbacks, support hours, and stabilization time. The trend should become more predictable. If defects remain constant, moving faster merely creates a larger problem backlog.
Separate migration defects from old defects newly exposed by better observability. Both need action, but correct classification keeps wave evaluation fair. Record temporary manual work as well; if it does not decline, the new architecture may not yet have simplified operations.
Using modes and agents to separate risk
NitroNet provides Draft, Sandbox, Production, and Disabled modes; separate Sandbox and Production endpoints; network-local receiving or sending agents; logs; and live testing. These support pilots and cutovers, while source applications, old consumers, and business reconciliation still require external coordination.
Database actions on one connection can be atomic; multi-database flows use Saga and compensation. APIs and email are at-least-once. Migration needs idempotency and reconciliation appropriate to each effect.
Review moving beyond point-to-point, duplicate-delivery risk, and safe retirement.
Design wave zero
Select one process with an active owner, test data, and a simple rollback. Run discovery, baseline, Sandbox, failure testing, shadow comparison, cutover, and retirement as a complete rehearsal. Data arrival alone is not success; prove totals, duplicates, missing records, access, recovery, and on-call operation.
Review wave zero with domain and operations teams. Change templates, capacity, and sequence from observed findings. Then choose the next wave with one additional level of complexity. Phased migration succeeds when risk falls and old paths close, not when the new workflow count merely rises.