Migration & Modernisation
Modernisation roadmap generator
Phase structure, exit criteria and indicative durations for an integration modernisation — including which phase usually absorbs the overrun.
Local files can contain entered information. Raw CSV preserves values and may be interpreted as formulas by spreadsheet software. Spreadsheet-safe CSV prefixes formula-like and leading-zero values with an apostrophe, changing those cells to text. JSON reports remain unchanged.
Save inputs locally to resume this tool. Files may contain sensitive entered information; review before sharing. No automatic storage or transmission. Report JSON is an output record, not an input import format.
Appetite
Waves with real exit criteria, parallel run per wave rather than across the programme.
- Phases
- 7
- Elapsed
- 47 weeks
- 10.9 months
Establish what actually exists: every interface, its owner, its volumes, its data classification and its cryptographic dependencies.
Exit criteria
- · Interface inventory reconciled against platform logs, not against documentation
- · Every interface has a named owner or is formally proposed for decommissioning
- · Volumes and peaks recorded per interface
- · Certificates and keys inventoried with expiry dates
Watch for The temptation to start building before the inventory is complete. Every overrun traced back to this phase started with someone saying the inventory could be finished in parallel.
Stand the platform up properly once, so no wave has to solve connectivity, security or promotion again.
Exit criteria
- · Environments provisioned with production-like connectivity
- · Source control, build and automated promotion working end to end
- · Secrets management in place, with no credentials in configuration
- · Security approval path agreed and evidence requirements known
- · On-premises agent or gateway deployed and reachable
Watch for Foundation work that gets deferred into wave one, where it costs the same but is now on the critical path.
Prove the platform, the pipeline and the deployment path on work where being wrong is survivable.
Exit criteria
- · Two or three low-criticality interfaces live on the new platform
- · Deployment performed by the pipeline, not by hand
- · Rollback rehearsed and timed
- · Estimates recalibrated against what the pilot actually took
Watch for Piloting on something important because it is 'more representative'. It is, and that is the problem.
Move the estate in waves, hardest and most critical first, with each wave independently reversible.
Exit criteria
- · Each wave has business acceptance before the next begins
- · Monitoring and runbooks migrate with each interface, not afterwards
- · Legacy platform proxies anything not yet moved
Watch for Waves that slip the hard interfaces to the end. Contingency is spent by then, and the hardest work lands with the least room.
Move trading partner connections, gated by their re-certification calendars rather than yours.
Exit criteria
- · Every partner re-certified on the new endpoints
- · Allow-lists updated on the partner side and confirmed
- · Fallback route to the legacy platform retained until each partner confirms
Watch for Treating partner work as a wave you control. It runs at their pace, and adding people to your side changes nothing.
Switch the old platform off, which is where the business case actually lands.
Exit criteria
- · No traffic on the legacy platform for an agreed observation period
- · Licences terminated or not renewed
- · Historical data archived per the retention requirement
Watch for A residual handful of interfaces nobody will take responsibility for moving. Name an accountable owner and a date, or plan to run both platforms permanently.
Hold elevated support while the new platform meets its first month-end, quarter-end and peak.
Exit criteria
- · First month-end and peak processed without intervention
- · Support handed to the run team with runbooks they accept
- · Defect rate trending down rather than flat
Watch for Ending hypercare on a date rather than on evidence. The first quarter-end is usually after the date someone picked.
How these durations were derived
- · 120 interfaces, 5 people, balanced appetite (1× on durations).
- · Waves with real exit criteria, parallel run per wave rather than across the programme.
- · Phases are shown sequentially. In practice discovery overlaps foundation, and partner conversations start in phase 0 regardless of when partner delivery lands.
- · Durations are calendar weeks, not effort. They assume the team is not also carrying production support for the legacy platform — if it is, add 30%.
- · On-premises systems add foundation time for gateway or agent deployment and the firewall changes behind it.
- · Partner migration is a separate phase because it is gated by other organisations' change calendars.
The phase structure generalises. Which phase your programme gets stuck in does not — and it is rarely the one people budget contingency against. Sequence the interfaces with the wave planner and check the prerequisites with the readiness assessment.
Durations are calendar weeks, not effort, and assume the team is not also carrying production support for the legacy platform. If it is, add roughly a third. Phases are drawn sequentially for clarity; in practice discovery overlaps foundation, and partner conversations start in phase zero regardless of when partner delivery lands.
More in this category
These exist because the underlying problem is real. If the numbers you just put in look uncomfortable, that is usually worth a conversation.
Stay ahead of the integration layer.
Integronauts Signal — practical enterprise integration, API and agentic AI thinking. The tools stay free either way.
Integronauts Signal is launching soon.
Practical enterprise integration, APIs, agentic AI and emerging architecture. Sign-up opens when the list does — nothing to enter yet.