Cloud modernisation programmes are rarely judged against the reason they were started, because the reason was rarely stated precisely enough to judge against. This paper offers a way to establish that baseline and to sequence work so that value appears before the budget runs out.
Modernisation decisions should follow from named business constraints, not from infrastructure age. This paper covers how to build a defensible baseline, how to classify an application estate, how to sequence work so benefits arrive early, and what has to be true operationally for the result to hold.
1. Establishing the baseline
Before deciding what to change, establish what you have and what it costs. Most organisations have an incomplete picture, and the gaps are usually in the same places.
The estate. Which applications exist, what business capability each supports, who owns it, what it integrates with, and what it runs on. The integration map is the part most often missing and the part that most often determines sequencing.
The true cost. Not just infrastructure and licences, but the support effort, the incident load, the delay each system imposes on change, and the specialist knowledge required to maintain it. A system that appears cheap on an infrastructure line may be consuming a great deal of senior attention.
The constraints. For each significant system, what can the business not do because of it? This is the input that determines value, and it must come from business leaders rather than from technology teams.
2. Classifying the estate
The familiar migration options — rehost, replatform, refactor, replace, retire, retain — are only useful once you know what each application is for. We suggest classifying first by business role.
Differentiating. Systems that encode something specific about how this organisation competes. These justify investment and should generally be refactored rather than replaced, because the logic inside them is the asset.
Necessary but undifferentiated. Payroll, expenses, standard CRM. There is rarely a case for bespoke work here; the question is whether the current instance is adequate, not whether it could be better.
Legacy with residual value. Systems still relied upon but no longer strategic. Often the right answer is targeted extraction — move the parts that constrain the business, leave the rest.
Candidates for retirement. Every estate contains systems maintained because nobody has confirmed they can stop. Confirming it is cheap and the saving is immediate.
Only after this classification does the migration-pattern question become answerable, because the pattern should follow from the role rather than from technical convenience.
3. Sequencing
Three principles produce sequences that survive contact with an organisation’s attention span.
Visible benefit early. Something a non-technical stakeholder can perceive should land in the first few months. Infrastructure work that enables later benefit is necessary but cannot be the whole first phase.
Alternate benefit and foundation. Pure foundation work loses support; pure benefit work accumulates debt that eventually halts progress. Alternating sustains both.
Follow the integration map. Applications with many downstream dependencies are more expensive to move and should generally be tackled once patterns are established — unless they are the constraint, in which case plan for the cost explicitly.
4. Architecture decisions that carry business consequences
How far to decompose. Finer-grained services offer independent deployment and scaling, at the cost of operational complexity that many organisations underestimate. The right granularity follows from how independently parts of the business actually need to change, not from an architectural ideal.
Where data lives. Often the hardest question. Shared databases are a common reason services cannot be deployed independently, which removes most of the benefit of separating them.
Managed versus self-operated. Managed services reduce operational burden and increase provider dependency. This is a legitimate trade rather than a principle; the relevant question is which dependencies you could tolerate and which would be existential.
Where state and identity are handled. Cross-cutting concerns decided late are decided inconsistently, and the inconsistency is expensive to unwind.
5. Security and resilience as design inputs
Cloud changes the shape of both. Identity becomes the primary control boundary. Configuration becomes a leading cause of exposure. Resilience becomes something you design rather than something the datacentre provides.
Recovery objectives should be stated per service and in business terms — how much data can be lost, how long unavailability is tolerable — because these drive architecture and cost more than almost any other requirement, and because uniform objectives across an estate are always wrong in one direction or the other.
6. The operating model after migration
The technical migration is the smaller half. What determines whether the result holds:
Cost ownership. Consumption-based infrastructure turns cost into a continuous engineering decision. Without visibility and ownership at team level, spend grows in ways nobody chose. This is the problem the FinOps discipline exists to address.
Platform responsibility. Someone must own the shared foundations — pipelines, observability, standards — as a product with users, not as a side responsibility.
Delivery capability. Modern platforms permit frequent, small, reversible change. Organisations that keep their previous release cadence acquire the operational complexity of the new model with none of the speed. The DORA metrics — deployment frequency, lead time, change failure rate, time to restore — remain a reasonable way to check whether the capability actually changed.
Skills. The operational skill profile shifts. Planning for this in advance is considerably better than discovering it during an incident.
7. Measuring whether it worked
Define success measures before starting, in the terms the constraints were expressed in.
- Time to make a representative business change, before and after.
- Change failure rate and time to restore.
- Total cost of ownership including support effort, not infrastructure alone.
- Whether the specific named constraints were actually removed.
That last one is the test that matters, and it is the one most likely to go unasked once a programme has its own momentum.
How VYSoft can help
VYSoft supports organisations through modernisation assessment, architecture and delivery planning, and the specialised capability needed at particular stages — with an emphasis on connecting technical decisions to the business outcomes that justified them.