Upgrade and migration planning

IT projects have a reputation for a reason. Timelines slip, costs creep, and businesses discover partway through that they do not have the internal capacity to run the project alongside the day job.

Underneath most of it is a scope that was never fixed. Every vendor answered a slightly different question, the comparison was meaningless, and the gaps surfaced during delivery when they were expensive.

Deadlines that force the decision

A lot of this work is triggered by an end-of-support date rather than a choice. Windows Server 2016 reaches the end of extended support on 12 January 2027, and Windows Server 2019 on 9 January 2029. Older Exchange and SQL Server versions, and hardware past warranty, reach the same point: after it, running them is a security and insurance problem rather than an IT preference.

Those dates are worth knowing about a year out, not a month out, because the difference is whether you run a selection process or accept whatever can be delivered in time. If you still run Windows Server 2016, you are already inside that year.

What you can buy here

Cloud migrations specifically

Cloud is sold as simple and rarely is. Legacy systems have dependencies nobody documented, and lift and shift often relocates the same problems onto a larger monthly bill.

I check what is actually being proposed against what your business runs and realistically will run: the architecture, the cost model at year three rather than year one, and whether you are buying capacity and complexity you will never use. I do this independently of whoever is presenting it, which is the entire point.

I spent five years designing and selling these solutions for integrators. That is why I know which parts of a proposal are load-bearing and which are there to make the number look better.

How delivery works

Scope first, written down, before anyone is asked for a price. That scope becomes the basis for quotes or a tender, so you are comparing like with like.

If you need people to deliver, I help you find and vet them rather than leaving you to assess CVs for work you do not do yourself. Every migration plan carries a defined rollback point agreed before cutover, so a bad night has a way back rather than an improvised one.

Then it gets validated against the original scope, confirming the system does what it was bought to do, not merely that it is running. This is the step that gets skipped when everyone is tired of the project.

The part most plans omit is the people. Migrations fail on adoption as often as on technology, so training and communication belong in the plan rather than in the week after go-live.

Who this is for

Businesses replacing ageing hardware, facing an end-of-support deadline, moving off an outgrown platform, or considering cloud for the first time. It is especially useful if you have never run a vendor selection, or if a previous project went badly and you want this one structured differently.

Common questions

Do you do the technical work or manage others who do?

Mostly the second, and deliberately. I scope, select, oversee and validate. For larger or specialised delivery I help you engage people who do that work daily, and I stay on your side of the table while they do it.

We have never run a tender. Can you help without taking it over?

Yes. I can run the whole process or support you at whichever stage you need, from writing requirements through to comparing final proposals.

How do you check a cloud proposal before we commit?

Against your actual current usage and realistic growth, looking at architecture, year-three cost and exit terms, independently of the vendor presenting it.

What if the migration goes wrong on the night?

Every plan has a rollback point agreed in advance. Knowing exactly when you stop and revert is what turns a bad cutover into a postponed one.

Next step

If a platform change, hardware refresh or cloud move is on the table, scope it before you talk to vendors rather than after. Book a 20-minute technology conversation.