Skip to content
Integronauts
← Tools
Integration & APIs

Modernisation roadmap generator

Phase structure, exit criteria and indicative durations for an integration modernisation — including which phase usually absorbs the overrun.

120
5

Appetite

Waves with real exit criteria, parallel run per wave rather than across the programme.

Phases
7
Elapsed
47 weeks
10.9 months
Phase 0Discovery and inventory6 weeksusually absorbs the overrun

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.

Phase 1Foundation6 weeks

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.

Phase 2Pilot3 weeks

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.

Phase 3Wave delivery14 weeksusually absorbs the overrun

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.

Phase 4Partner migration10 weeksusually absorbs the overrun

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.

Phase 5Decommission4 weeks

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.

Phase 6Hypercare4 weeks

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.

Other tools

These exist because the underlying problem is real. If the numbers you just put in look uncomfortable, that is usually worth a conversation.

Tell us what you're running