Skip to main content
ProtoComet
ProtoComet

  • Getting to Azure is the easy part. Arriving with something better is the job.

    Modernize legacy systems and evolve your cloud architecture with a clear understanding of what to change, what to retain, and why. Get independent guidance grounded in your existing technology, business priorities, and long-term direction.

Where this actually breaks

Most migrations don’t fail on the technology. They fail on a few early decisions that were made by default instead of on purpose. These four come up most often.

Everything is moved as it is

Rehosting every server unchanged is the quickest plan to deliver and the simplest to price, so it often becomes the default. Without a decision for each workload, you end up with the same estate, the same problems and a higher monthly bill.

The move order is set by convenience

Waves get grouped by department, or by whatever is easiest to move first, rather than by what depends on what. A database moves early, the application that relies on it moves months later, and users feel the slowdown in between.

The pilot was a development box

A test server moves cleanly and the approach is declared proven. But it had no real users, no integrations and no month-end close. The first production workload becomes the real test, and it arrives with no evidence behind it.

"Done" means it is running, not that it works

A wave is marked complete once the servers are up in Azure. Whether month-end still closes, backups still restore and integrations still connect gets found out later, usually by the business, and usually at the worst possible moment.

Six checkpoints, from first inventory to final switch-off

Two checkpoints happen before anything moves. Three repeat with every wave. One closes the programme. Each ends in a short written decision that everyone works from, so the plan, the build and the sign-off are all checked against the same record.

1. Decide what moves, and how

Start from what is actually running. Each workload gets a decision: move as is, modernize, rebuild, replace or retire, with the reasoning written down. Moving as is has to earn its place like any other option.

Output: Decision register

2. Plan the order

Group workloads by what depends on what, and by risk. Retire what isn’t needed first so it never gets moved at all. Choose a pilot with real users and real integrations, so that passing it actually proves something.

Output: Wave plan, pilot brief

3. Review each wave’s design

Before a wave is built, check its design against the decisions and the Azure foundation it will sit on. Any change from the plan is agreed or turned down in writing before work starts.

Output: Review note per wave

4. Sign off go-live

An independent checklist before every cutover, backed by evidence: the data matches, the numbers reconcile, performance holds, costs are as expected, support is ready and the rollback has been rehearsed.

Output: Go-live record

5.Reconcile

Compare actual cost and effort with the plan, and confirm the old servers are really switched off. Explain any gap to the budget owner while there’s still time to adjust the next wave.

Output: Wave report

3. Hand over

Hand the estate to whoever will run it, along with the decision register, runbooks and open items. Include a clear recommendation on whether it needs ongoing oversight to stay the way it was designed.

Output: Close-out report

How the work actually runs

A standing retainer for the length of the programme, because the value is in being there at every gate rather than in a report at the start. The portfolio read can be bought alone, fixed price, if what you need first is a second opinion on the plan.

Start with a plan review, fixed price


Before the first wave, you get the decision register and the wave plan, built on your own discovery data and delivered in 2-4 weeks. This is often where a move-everything-as-is plan picks up retirements and modernization, and ends up with a smaller monthly bill. You can stop here and keep the plan.

Stay through every wave, monthly


A fixed monthly fee for as long as the migration runs. It covers the design reviews, go-live sign-offs, wave reports and quick access for decisions that can’t wait. The fee depends on how often waves happen, not on how many servers move. Cancel with a month’s notice.

One senior person, start to finish


The person who signs off go-live is the same person who made the workload decisions and reviewed the design. Nothing is handed to a junior team or a committee. If a wave is held back, your team and your partner get the reason in writing, the same day, from the person who made the call.


What you walk away with

The documents are the evidence. What matters is what they leave you with.

➖ An estate built on purpose. Every workload was moved, modernized, replaced or retired for a reason, so it isn’t a copy of the old setup in a new place.


➖ Old servers that are really gone. Decommissioning is confirmed for each wave, so you aren’t paying for two estates months after the migration “finished”.


➖ A team that can run it. Runbooks, open items and the reasoning behind each design are handed over, so the knowledge stays with you and not with whoever did the delivery.

➖ No surprises at go-live. Every cutover was checked against evidence before it happened, and the rollback had been rehearsed in case it was needed.


➖ A record you can rely on later. When an auditor, a new hire or your next partner asks why something was built that way, the answer already exists.


➖ A budget you could see coming. Actual cost and effort were compared with the plan after every wave, so overruns showed up while there was still time to change course, not in the final invoice.

Our Way

Large enterprises don’t migrate without an architecture review board, a change authority and a programme office checking every step. That’s why their migrations usually land. Most growing companies can’t justify any of that, so the checks simply don’t happen.

ProtoComet fills that gap with one senior person rather than a department. You get the same decisions, reviews and go-live sign-offs a large enterprise would insist on, sized to your estate and your budget, and with none of the committees that slow big programmes down.

You keep the speed of a small team. You stop relying on luck.


You only migrate once. Moving the same problems to Azure is the most expensive way to keep them.


Yogesh, founder and principal consultant

Questions clients typically ask

Answered directly. If the honest answer is "it depends", the dependency is named.
No. The plan review can cover the remaining waves, the go-live sign-off can start at the next cutover, and the wave reports can be filled in for the waves already done. It is most useful before the first wave, but many clients arrive after a wave has gone badly, and the engagement is designed to start there too.
Yes, and it’s often where it helps most. A small in-house team is building, testing and signing off its own work under the same deadline. ProtoComet provides the decisions, reviews and independent sign-off around them, so your team can focus on the work itself.
Not if it’s sized properly. You don’t need a programme office, just the few decisions that matter made deliberately and checked before go-live. The engagement scales with how often you run waves, not with the size of your estate. For a small migration, the fixed-price plan review on its own may be all you need.
You do. ProtoComet’s sign-off is a recommendation backed by evidence, not a veto. If you decide to go ahead, that decision and the reasons for it are recorded, so everyone knows who made the call and why.

Yes. For legacy .NET estates, Implementation & Governance is the service where ProtoComet delivers the waves end to end with a named senior team. This page is for the other case: someone else is delivering, and you want independent decisions, reviews and go-live sign-offs over their work.

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