Development & Application Modernisation

How do you decide what to modernise first?

By assessing applications against two axes rather than one: how much pain each causes, and how much value would be released by changing it. Business criticality on its own produces the wrong order, because the most critical application is usually also the most frightening to touch, so the plan stalls at item one.

What we look for instead is the highest-pain, highest-value piece, which in practice means whatever generates the most support tickets, whatever blocks the features the business actually wants next, or whatever single system is holding an entire platform decision hostage.

The assessment itself is unglamorous and it is where the cost of the whole programme gets decided. For each application we establish what it genuinely does, including the parts nobody documented; who uses it and how often, because usage is regularly a fraction of what people assume; what it depends on and what depends on it; whether the vendor still exists and still supports it; what data it holds and where that data goes; and what the platform underneath it is, along with how long that platform has left.

The output is a ranked roadmap where each item names the route, the reason and the trigger, so the sequence survives contact with a busy quarter rather than reverting to whatever is loudest.

Rehost, replatform, refactor or replace: which applies?

The four routes answer different questions, and the mistake that costs the most is choosing one for the whole estate. Rehost, often called lift and shift, moves the application as it is onto new infrastructure without changing it: fastest, lowest risk, and it fixes exactly one problem, which is the hardware or datacentre underneath.

Replatform keeps the application broadly intact but swaps components for managed equivalents, most commonly moving a database onto a managed service or a web tier onto an app service, which removes patching and capacity work without touching the code that carries your business logic.

Refactor changes the application itself, usually to break a monolith into pieces that can be deployed and scaled separately, or to rewrite one part that has become the constraint. Replace retires the application in favour of something else, whether a product you buy or something built new. The decision rule we use is simple: work out what the actual problem is first.

If the problem is the platform, do not touch the code. If the problem is one component, do not rebuild the whole thing. If the problem is the business logic rather than the technology, replatforming faithfully just gets you the wrong thing on newer infrastructure. Most estates end up using two or three of these routes across different applications rather than committing to one.

Why does lift and shift produce a bigger bill than expected?

Because a server sized for a five-year on-premises life gets recreated exactly as it was, and cloud charges by the hour for capacity you owned outright before. On-premises, an oversized machine costs you nothing extra once it is bought; the waste is invisible and permanent. Rehosted, that same over-provisioning becomes a monthly invoice line that grows with every server you move.

Add the components that used to be free because they were already in the building, storage tiers chosen out of habit rather than measured need, backup and data transfer, and non-production environments left running around the clock, and the total lands well above the business case.

That work is the same discipline as our cost management and Azure optimisation service, and it belongs in the plan from the start. A migration with no optimisation phase scheduled after it is a migration that will produce an uncomfortable invoice review in about four months.

Why do big-bang rewrite projects fail to ship?

Three reasons, and they compound. Scope creep, because the existing application contains undocumented business rules, edge cases nobody remembers the reason for and integrations quietly holding three other systems together, all of which surface one at a time during the rebuild.

The business does not get to pause, so the old application has to keep running in full for the entire project, and every hour spent on the new system is an hour not spent improving the one people are actually using. And timing: rewrites commonly take twelve to eighteen months, sometimes longer, by which point the requirements captured at the start have moved, and you can end up delivering a faithful rebuild of a system the business has already outgrown.

The structural problem underneath all three is that a big-bang rewrite has to work perfectly on day one to be worth anything. Until the switchover, every penny spent is sunk cost with nothing running to show for it, which is also why these projects are so easy to descope or quietly abandon six or nine months in when budgets tighten.

The people who authorised it have seen no value, so there is nothing to defend. That is not an argument against ever rebuilding. It is an argument against making the whole thing contingent on a single future date.

What does incremental modernisation actually look like?

It replaces a legacy system piece by piece, from the outside in, in what is usually called the strangler pattern. You put a stable interface in front of the old application, then build new components behind it one at a time, routing traffic to each new piece as it becomes ready.

The legacy system keeps handling everything not yet rebuilt. Nothing is switched off until its replacement is already carrying live traffic successfully, which means there is no single switchover date on which everything has to work, and no point at which the business is betting on a future event.

Two ordering rules make the difference between this working and becoming an expensive rewrite in slow motion. Move data and integration layers before touching the interface: getting the data into a stable home and building solid APIs around it gives everything else a foundation, and it is usually less politically sensitive than changing a screen people use every day.

And build the new pieces on managed platform services rather than recreating the old architecture in a new location, because rebuilding the same design on newer infrastructure inherits the constraints you were trying to escape. Each increment has to be genuinely deliverable on its own, or you have simply broken a rewrite into instalments nobody can use.

What does running old and new side by side actually cost?

That is a real cost, and pretending otherwise is how incremental programmes get sold optimistically and then judged harshly.

The reason it is still usually the better trade is that the cost is bounded and visible, whereas the risk it removes is neither. A big-bang cutover concentrates all the uncertainty into a single weekend, with a rollback plan that gets less credible the longer the new system has been taking transactions.

Incremental transition spreads that risk across many small, reversible steps. The discipline that keeps the cost bounded is refusing to let the transition period drift: each increment should have a defined point at which the old path is switched off and decommissioned, because parallel running that never ends is the most expensive outcome available.

Where does Power Platform genuinely fit, and where does it not?

It fits best where the work is forms, workflow, approvals, and putting a usable interface on data that already lives in your Microsoft estate. A departmental process running on a spreadsheet and an email chain, an approval flow currently maintained by someone remembering to chase people, a request or booking system nobody has ever had the budget to build properly: these are exactly what Power Apps, Power Automate and Dataverse are for, and building them conventionally is usually poor value.

It also fits as the extension layer around a system you are not replacing, adding the workflow the core product does not do rather than customising the core product into something unsupportable.

Where it fits poorly is high-volume transaction processing, genuinely complex algorithmic logic, anything with hard real-time performance requirements, and anything that needs to be portable off the Microsoft platform later. There is also a governance dimension that gets discovered late: low-code makes it easy for anyone to build something the business then depends on, which is how organisations accumulate a second shadow estate with no owner, no documentation and no lifecycle.

Licensing needs checking against the actual usage pattern before you commit, because the model differs by connector and by app type and is not something to assume. Used deliberately it is one of the highest-return tools available. Used as a default answer, it becomes next decade's legacy problem.

What about data, APIs and the integrations nobody documented?

The integrations are usually the actual project. Almost every application that has been in service for years has grown connections nobody wrote down: a nightly file drop another system depends on, a database view someone else's reporting tool reads directly, a scheduled task that emails a spreadsheet to finance, a hard-coded server name inside a third system.

Discovery has to find these before anything moves, because each one is a way for a successful migration to break something in an unrelated part of the business a week later.

The remedy is to put a deliberate interface where an accidental one grew. Replacing direct database access with a documented API is often the single highest-value early increment, because it decouples everything downstream from whatever you do next and lets you change the system behind it without renegotiating with every consumer.

Data needs its own plan alongside: what is migrated, what is archived, what is deliberately left behind, how the two sides stay consistent during transition, and how you prove afterwards that nothing was lost. Getting that plan wrong is the failure that is hardest to correct retrospectively, because by the time anyone notices, months of new transactions sit on top of it.

When is a full rebuild genuinely the right answer?

In two situations, and it is worth being strict about them. The first is when the underlying platform is fully unsupported or unsupportable, so there is no stable base left to build anything around: you cannot incrementally strangle a system that will not run on anything you are allowed to deploy.

The second is when the business logic itself is wrong rather than the technology it is built on, because a faithful replatform of the wrong process delivers the wrong process, faster and on a better invoice.

Even then, the runway question decides the approach. A rewrite is commonly a twelve-to-eighteen-month undertaking, and an application sitting on an already-unsupported operating system rarely has that time available. Where that is the case, capture-based migration onto a modern supported platform buys the breathing room, and the rebuild happens on its own timeline rather than against a security deadline.

That is a bridge rather than a destination, and it should be called one in the plan. The failure mode is treating the bridge as the answer, then finding four years later that the temporary arrangement is now the thing nobody dares touch.

What does modernisation done properly look like?

The test is whether value arrived before the project finished. A programme running properly has shipped something usable within the first few months, has an explicit route recorded for every application in the estate including the ones deliberately left alone, has decommissioned at least some of what it replaced rather than accumulating both, and has a cost picture that someone reviews rather than discovers at renewal. It also has fewer surprises over time rather than more, because discovery work done early is what removes them.

And then drifted for a decade.

Avoiding a repeat means naming an owner, keeping dependencies current rather than pinned, keeping the deployment process automated so releasing is routine, and writing down enough that the next person does not have to reverse-engineer it. Modernisation that produces a better system with the same neglect around it has bought you roughly ten years.

How does this relate to legacy migration, packaging and cost work?

They meet constantly and are usually cheapest scoped together. Our legacy modernisation and OS migration service deals with the platform underneath: Windows and Windows Server versions going out of support, and applications that cannot move because the install media, the source code or the vendor no longer exists.

That is frequently the trigger for a modernisation conversation rather than a separate matter, because an end-of-support date is a deadline the business cannot argue with, which makes it the moment the awkward application finally gets attention.

Application packaging and MSIX is the delivery side of the same problem: once an application has been captured or rebuilt, it still has to reach users reliably and repeatably, whether that is on managed desktops, in Azure Virtual Desktop host pools or on Windows 365 Cloud PCs.

And cost management and Azure optimisation is what stops a successful migration turning into an unpleasant invoice, which is why we schedule it after a rehost rather than treating it as an unrelated engagement. If your modernisation is really an end-of-support problem, or really a cost problem, we will say so rather than selling you the more expensive interpretation.