Skip to main content
ProtoComet
ProtoComet

  • Get modernization delivered as planned, and keep the new one from ageing.

    The remaining waves are delivered against your roadmap, each one passing a go-live check before the old system is switched off. A monthly review then keeps architecture, costs and versions from drifting back.

Where this actually breaks

By this stage the design is proven. What goes wrong now usually happens in the gaps: between one wave and the next, between the plan and the bill, and between switched over and actually finished.

The old system never gets switched off

Both systems are live and both are being paid for. Nobody will sign off the switch-over, because nobody wrote down what sign-off requires. A year later the old servers are still running, just in case.

The Azure bill arrives and nobody can explain it

The estimate came from the cost model and delivery followed the wave plan, but nobody compared the two as the waves went live. The difference can usually be explained. It rarely is, until someone asks.

The new system starts ageing on day one

Without regular review, the modernized system collects the same drift the old one did: a manual fix here, an unreviewed Azure resource there, a .NET version quietly falling out of support, until an audit finds it.

AI-written code drifts from the design

AI coding tools speed up every wave, but each one is used differently. Data access, error handling and logging end up written three different ways, and the gaps only show when something fails in production.

Waves and gates: how each wave is delivered and kept current

Steps 1 to 5 repeat for every wave in your roadmap and make up Tier 4. Step 6 is Tier 5, which starts the month the last wave goes live. Each wave moves forward only when its written criteria are met.

1. Plan the wave

The applications in the wave, the migration approach for each from Tier 2, and the go-live criteria. All of it is agreed and written down before any code changes, so everyone knows what finished means.

Per wave · wave charter

2.Build

Each application is modernized to the agreed architecture. Every change, including AI-generated code, is reviewed against the Tier 2 design, and any departure from it is recorded with the reason.

Per wave · modernized applications

3. Run in parallel

The old and new systems both run live, with traffic moved across in agreed steps. The run has a set length and a tested way back, and both systems are measured on the same dashboards throughout.

Per wave · run evidence

4. Go-live check

A written checklist that each wave passes or fails, agreed in the wave charter. If it fails, the parallel run continues or traffic moves back, and the reason is carried into the plan for the next wave.

Per wave · go-live record

5.Decommission

Old servers shut down, licences released and the saving checked against the roadmap’s estimate. This step is where most of the cost benefit is realized, so it’s tracked as closely as the build.

Per wave · cost check

6.Govern

Every month: architecture drift, costs against the running-cost estimate, framework and platform versions, and a ranked list of what to change next. Every quarter: a one-page summary for leadership.

Tier 5 · monthly report

How the work actually runs

Tier 4 is priced one wave at a time, and Tier 5 is a monthly retainer. At every stage you can see what’s been spent, what’s left and where you could stop.

Tier 4: wave by wave


Each wave is scoped on its own: fixed price where the pilot has proven the estimate, and billed monthly where it hasn’t. Either way, there’s a stop point at every month end, and you commit to one wave at a time.

Tier 5: with a defined cadence


A fixed monthly cadence: the monthly review, the quarterly board summary, and a standing line to the architect for decisions that cannot wait. Cancellable it is designed to be worth keeping, not hard to leave.

One senior consultant throughout


Every go-live is signed off by the senior consultant who designed the architecture. Specialist engineers join when the scale needs it and work to that design, so the standard holds from first wave to last.


What you walk away with

For every wave, modernized applications and the records that show they’re done. Under Tier 5, a monthly view of how the system is holding up and what to change next.

➖ Wave charters. The applications, migration approach and go-live criteria for each wave, agreed and written down before the wave begins.


➖ Design change register. Every departure from the Tier 2 design, why it happened, and whether it should become part of the agreed architecture.


➖ Switch-off and cost records. What was shut down and when, the licence and hosting cost released, and actual spend against the roadmap’s estimate.

➖ Modernized applications. Each wave live on the new architecture, with its deployment pipeline, monitoring and runbooks for day-to-day operation.


➖ Go-live records. The checklist and evidence for every go-live, including any that failed, what caused it and what changed as a result.


➖ Monthly and quarterly reports. A monthly report on drift, costs and versions with a ranked list of next changes, plus a quarterly page for leadership.

Our Way

Every legacy system was once the modern one. WebForms replaced classic ASP, and WCF replaced a set of DCOM components. Each was delivered by a project that ended at go-live, and each started to drift soon after, because nothing was in place to keep it current.

That’s why delivery and governance are designed together. Each wave has go-live criteria agreed before it starts, and switching off the old system is a step with its own deliverable, because that’s when the savings in the roadmap actually arrive.

After the last wave, a monthly review keeps the architecture, costs and versions in line, so the system you paid to modernize stays easy to change and doesn’t become the next legacy.

Modernization is finished when the old servers are off, the bill matches the estimate, and someone still owns the system a year later.


Yogesh, founder and principal consultant

Questions clients typically ask

Short, direct answers about the assessment itself. Questions about the wider engagement are answered on the .NET Modernization overview.
Wave by wave. Where the pilot has proven the estimate, a wave is fixed price. Where it hasn’t, it’s billed monthly. Either way, you commit to one wave at a time, there’s a stop point at every month end, and anything unexpected is raised that week with its cost shown before work continues.
Only if a proven design already exists. Tier 4 delivers against an agreed architecture and a pilot that tested it. Without them, the first wave would carry all the risk the pilot is meant to remove. If you have an existing design, we review it first, and a short design and pilot phase can run as part of the first wave if needed.
The two overlap, so you don’t pay for both. A Fractional CTO retainer includes this governance as one of its standing responsibilities, and Tier 5 is folded into it. Tier 5 suits you when you need the systems looked after. The retainer suits you when you need someone to own the technology strategy.

Yes. Each wave is planned only when the previous one is close to finishing, so a new business priority, a budget change or a lesson from the last wave can reshape what comes next. The roadmap is updated, and you see the effect on cost and timing before you agree.

The monthly reports show it. When drift stays low for several months and your team is running the same review on its own, the retainer has done its job, and we’ll suggest stepping back to a quarterly check or ending it.

Ready to move?

Let's talk about where you are and where you want to go.  and whether modernization is even the right answer this year. If it is not, you will hear that.

Let’s Talk