Cloud adoption is no longer the main challenge for most organisations. The harder problem is operating what comes next: growing complexity, unclear ownership, inconsistent standards, and manual workarounds that become permanent.
Over time, this operational load consumes the capacity needed to improve. Pragmatic modernisation starts by creating visibility, making deliberate trade-offs, and building the shared disciplines required to change safely.
Operational complexity rarely comes from one bad decision. It usually develops through many reasonable decisions made in isolation.
A team needs to deploy quickly, so it creates its own delivery process. Another team adopts a different monitoring tool because the organisation’s standard tool is difficult to integrate. Someone makes a manual change because the standard process will take too long.
Eventually, the environment contains:
Each additional variation increases the effort required to understand and govern the environment. Platform and architecture teams become bottlenecks, delivery slows, and technical debt becomes harder to resolve.
Top Tip: Watch out for unintentional satellite architecture
A common symptom of this type of ungoverned complexity is an unintentional satellite architecture. The organisation may appear to have one cloud platform, but individual workloads operate as small islands. Each has its own deployment process, monitoring, ownership model, security assumptions, and support practices. The problem becomes obvious when these workloads need to integrate, share data, meet common controls, or merge to eliminate duplication.
For modernisation to be achievable, it should connect business intent with technical reality.
Business intent might be to improve resilience, reduce delivery time, lower operating cost, or enable a new digital capability.
Technical reality might include manual provisioning, unsupported systems, duplicated platforms, poor observability, or limited engineering capacity.
A useful strategy makes the relationship between the two explicit. It should define:
For example, an organisation may choose to standardise new workloads on a small number of supported patterns. This might reduce team-level flexibility, but improve deployment consistency, supportability, and governance. That trade-off should be intentional rather than accidental.
Top Tip: Hold a decision register
Technical decisions often lose their context over time. A lightweight decision register can help. For important decisions, record the problem, the selected option, the alternatives considered, the trade-off accepted, and the evidence that would cause the decision to be revisited. This avoids reopening the same debate and helps future teams understand why a standard exists.
Before changing an environment, you need a reliable view of its current state. This includes more than an inventory of cloud resources. Useful visibility covers four areas:
Organisational: Who owns the system, supports it, and makes decisions?
Architectural: What are its dependencies, interfaces, data flows, and failure points
Operational: How is it deployed, monitored, secured, and recovered?
Traditional practices still matter. Process maps, architecture documents, RACIs, and conversations with subject-matter experts provide context that tools cannot discover automatically.
Programmatic evidence is also important. Configuration data, telemetry, change history, security findings, and cost records provide a repeatable view of what is happening.
The goal is not perfect documentation. It is enough trustworthy information to make decisions without beginning every discussion with a discovery exercise.
Top Tip: Observability is not enough
Observability is the mechanism that enables us to investigate system behaviour using telemetry such as logs, metrics, and traces. Operational visibility goes further by connecting runtime evidence with architecture, ownership, cost, risk, and business intent.
Telemetry without business context tells you something is wrong. It does not tell you who should act, what matters most, or what trade-off is appropriate.
Once the environment is understood, standardise the concerns that teams shouldn’t need to solve repeatedly. Typical examples include:
Standardisation does not mean every workload must look the same. It means creating consistent boundaries, controls, and supported patterns in the areas that matter most.
A practical model is:
This gives teams a clear starting point while preserving room for justified variation.
In one environment we worked with, software and data teams had adopted several tools for similar tasks. The platform team struggled to support them consistently and had limited visibility across the estate. The organisation reduced the supported toolset, introduced shared deployment patterns, and created self-service paths with governance built in. The main benefit was not simply having fewer tools. It was being able to build deeper expertise, automate more controls, and give teams a reliable way to deliver.
Everything in the platform should earn its place. If a tool or pattern does not improve delivery, control, resilience, or supportability, its operational cost should be questioned.
Top Tip: Infrastructure as Code scales decisions
Infrastructure as Code makes infrastructure repeatable, reviewable, and testable. It is most effective when ownership, patterns, and interfaces are already clear. It can also, however, amplify poor organisational practices.
Automation does not remove architectural problems. It increases the speed and consistency with which a design is applied. Reusable modules should therefore represent agreed patterns, not simply convert existing manual processes into code.
Governance is often treated as a central approval process. This can create control, but it can also create delay and push teams toward workarounds. Effective governance should make routine decisions easier. It should define:
Where possible, controls should be embedded into delivery processes through policy as code, automated testing, deployment pipelines, configuration checks, and drift detection. However, even without these controls, a shared set of strategic principles and standards gives teams the ability to make decisions that align with strategy.
The aim is not to block every decision. It is to provide fast feedback, clear remediation, and an auditable exception process.
“Highly available” is not a meaningful requirement on its own. Teams need to understand acceptable downtime, recovery expectations, failure scenarios, and the business impact of disruption before making a strategically aligned decision.
Clarity early is usually cheaper than redesign later.
Modernisation should respond to what the environment is telling you. The priority is not change for its own sake, but targeted improvement that reduces complexity, addresses risk, and creates measurable value.
The choice should reflect:
Lift and shift can be a useful step, but it is not a business outcome. Moving a system without changing how it is operated may simply relocate its existing complexity.
In one migration, the original plan was to move a critical system largely unchanged and optimise it later. As the team understood the workload in more detail, it became clear that some components had different requirements and could be modernised earlier.
Changing the approach reduced cost sooner and shortened the path to value.
The broader lesson is not that every migration should include immediate refactoring. It is that planned future value remains an assumption until the technical details support it.
Top Tip: Aim for progressive value
Long programmes that defer value until the final phase carry significant risk. Assumptions may change, priorities may shift, and organisational support may weaken. A pragmatic roadmap should deliver useful increments. Each step should remove a constraint, reduce risk, improve operating capability, or provide evidence for the next decision.
Progressive value does not mean choosing only easy work. It means ensuring that difficult work creates measurable benefit along the way.
Frameworks such as the AWS Well-Architected Framework can help identify risks, test assumptions, and structure improvement priorities.
They are most useful as lenses rather than answers. A review can show where a workload is weak, but the organisation still needs to decide which risks matter most, what trade-offs are acceptable, and who owns the improvement.
The same applies to cost. The cloud invoice is only one part of Total Cost of Ownership. Support effort, incidents, licensing, engineering time, business disruption, and the remaining life of a system may be equally important.
Modernisation decisions based only on infrastructure spend are likely to miss the larger cost of operating the system.
A few practical principles can be immediately adopted to keep modernisation grounded.
The best solution is not always the most technically advanced. It’s the one that meets business needs reliably, securely and at an appropriate cost.
Good engineering supports the outcome rather than becoming the outcome. Chasing the latest and greatest can add complexity without creating value.
Align decisions with strategy, then build what is needed now. When requirements change, refactor, when the strategy evolves, adapt your approach.
The reason is simple: future requirements are uncertain. Designing for too many possibilities increases cost and complexity and often results in capabilities that are never used.
Before adopting a new tool, pattern or architecture, share the decision and gather feedback.
The aim is not to create an endless technical debate. It is to identify risks, incompatibilities and duplication before they become embedded.
Decisions made in isolation are the primary source of unnecessary complexity. Early alignment makes change easier to support later.
Pragmatic modernisation is not about choosing the newest technology or designing the perfect future state. It is about understanding the current environment, agreeing on the outcomes that matter, and making deliberate improvements without creating another layer of complexity. That requires clear ownership, useful standards, reliable evidence, and governance that supports delivery. When those disciplines are in place, modernisation becomes less of a rescue exercise and more of a normal part of operating technology well.