Cloud Native is not the destination. It's the journey!

Doing “Cloud Native”

The phrase alone conjures visions of dynamic, scalable platforms, self-healing applications, and empowered development teams shipping faster than ever before. But for many organisations, the reality of “doing Cloud Native” falls far short of this ideal. They migrate to the Cloud, tick the Kubernetes box, slap on a developer portal, and declare Mission Accomplished (puff puff bang confetti). Unfortunately, the destination doesn’t look like the promised land. Costs have ballooned, developer experience has tanked, and the only thing that’s scaled is the complexity.

What’s going wrong?

The issue is simple: Cloud Native isn’t a destination, it’s a way of work. It’s not about deploying specific technologies. It’s about developing capabilities that unlock agility, scalability, and resilience. And from our experience, it’s a journey few are truly prepared for. Below we explore the common pitfalls which have become far too synonymous with Cloud Native Modernisation projects:

The Fallacy of the Lift-and-Shift

Too often for our liking, organisations have began to equate Cloud adoption with Cloud Native. Their projects lift monolithic applications and infrastructure into the Cloud as-is, thinking they’re unlocking Cloud Native benefits. Unfortunately, for the most part, all they’ve really done is swap one set of costs and constraints for another set of challenges. Now for some organisations, they are more adaptable to these new challenges and the cost / reward is realised, but for the rest? Well, they’re still scaling vertically, they’re still operating monoliths, but worse still, they’re now locked into ecosystem which charges you for dynamic capabilities they have no option of using.

The fallacy of the lift and shift needs to stop. Cloud Native is not about infrastructure location. It’s about how you build and operate systems. It’s about architecting for change, not just moving existing problems somewhere else to realise fringe eco-system benefits.

Cloud Native means rewriting the rules

A common misconception is that Cloud Native Projects are all about the technology, but we often see the biggest hurdles based around people and processes ingrained within an organisation. Whilst seeking true Cloud Native adoption means embracing distributed systems, decoupled architectures, and horizontal scalability are a must, of equal importance is the requirement to rethink the relationship between people, process, and the technology.

We’ve got five handy pointers below to help detail what this includes:

• Decentralised ownership: Developers can build, test, and deploy independently.
• Resilience through redundancy: Failures are expected, not exceptional.
• Automation as default: Manual intervention should be a last resort.
• Product thinking: Platforms are treated as products, with roadmaps, KPI’s, and customer feedback loops.
• Organisational flex: It’s not just a tech upgrade, it’s an organisational review.

Focus on productivity, not just cost savings

Another recurring theme in Cloud Native project failures is the expectation of cost savings. “Move to the Cloud and save money,” goes the pitch. But while Cloud Native approaches can reduce CapEx and in some cases OpEx costs, the immediate benefit projects should be seeking is developer productivity. If you adopt Cloud Native practices which align with your business you will see accelerated development cycles, reduced time-to-market, and developers empowered to deliver value faster and to more customer opportunities.

How are you monitoring the success of your infrastructure platform and development teams? Are they simply a line item on a balance sheet? A cost of doing business? Or do you see these departments as an innovation center? An engine which provides agility, options, meeting business opportunities and growth? Delivering your product to more customers, in more environments with a continuous stream of well tested and competitive features?

Even when treated as a balance sheet objective the debt of doing it wrong will always need to be paid. The famous five year throw-it-away-build-it-again cycle incurs a regular heavy cost both financially and culturally. Organisations who only innovate and develop capabilities when packaged as big awe-inspiring projects are the exact organisations who need to ask why this is the only way they attempt to deliver cross-team, foundational, productivity focused work? Break the cycle and focus on incremental costs and gains with continuous improvements in operational and development productivity.

Technology is not the capability

This is a big one. Regardless of project maturity, this can create confusion with every role throughout the project lifecycle. Therefore, one of the most damaging habits we see in the Cloud Native space is confusing a technology or a product with a capability. How many times have you been in a meeting and heard the following phrases? “We’ve implemented Vault, so we’ve solved secrets management.” “We’ve adopted Kubernetes, so we’re Cloud Native.” “We’ve deployed Backstage, so we’ve nailed developer experience.”

It’s a common pitfall, when these teams declare Mission Accomplished (obligatory puff puff bang confetti) to not lead with the limitations, something much easier to do when discussing a specific technical capability rather then a technology choice. For instance, “we have delivered Vault” (confetti at the ready) versus, “our secrets management capability now supports AWS trust relationships.” We know it doesn’t sound as spiffy but on the other hand you reduce the chances of teams assuming functionality which isn’t there and now needs to be rapidly delivered because “your service is the only blocker”

This should be a huge learning for a Cloud Native project: “Capabilities must come first. Technologies come second.”

Developer experience is earned, not installed

At KubeCon London 2025 it was very apparent that it’s fashionable to prioritise “self-service” platforms. Backstage. Internal Developer Platforms. Golden paths. Unfortunately, we see many teams try to leap straight to a slick interface without doing the hard work first. But the hard work is necessary.

This involves talking to developers, understanding workflows, setting clear boundaries of responsibility, and building trust. If you fall into the trap of avoiding this engagement and trust building phase, your are very much in danger of your developers being handed tools they don’t understand, they can’t use effectively, and they weren’t even consulted about. The common result? Resistance. Shadow ops. Frankenstein pipelines. Or worse still, a black box of individual, “organic”, developer built functions which now contain critical workflow logic.

The big learning for this pitfall is “You can’t retrofit developer experience.” It needs to be prioritised from the very beginning of your journey, and it results from the hard work. The best results are from good communication, iterative development, and, most of all, enablement.

You can’t bolt-on Cloud Native

Whilst similar to “the lift and shift fallacy”, to unlock the true benefits, Cloud Native must be designed in at the start, not added on at the end. You can’t “go Cloud Native” by wrapping your legacy systems in containers and hoping for the best. The same is true for FinOps, security, and resilience. These key words aren’t departments, tools or bolted on products. They need to be cross-cutting concerns that must be integrated into the design of your Platform from day one.

If you are to take away one key point from this section, it’s to design for Cloud Native at the start, because waiting to fix issues such as cost visibility when the CFO sees the bill is too late. Waiting to secure your stack before an upcoming audit is too late. Waiting to optimise developer workflows when morale is about to crash is too late.

KPIs that mean something

I’m sure we have all been on projects with either no KPI’s, or KPI’s that make the team appear good rather that prove value is being delivered. Unfortunately, you can’t measure success if you don’t define it properly.

The adoption of meaningless KPI’s include:

• API calls
• Container counts
• Uptime percentages detached from value.

Meaningful KPI’s for real Cloud Native success should include indicators such as:

• Time from code commit to production
• Mean time to recovery
• Frequency of deployments
• Developer onboarding time
• Cost per feature shipped

So what is the key learning here? If your metrics don’t reflect capability, you’re flying blind.

What key points do you address to be Cloud Native?

While the challenges may appear straightforward, the path to resolving them is anything but. We see it very often that organisations reach for a new tool or platform in hopes of solving deep-rooted issues, when in reality, technology is rarely the core problem. The real friction lies within people, culture, and practice. These are areas that resist quick fixes and require uncomfortable introspection. Unlike writing code, evolving deep rooted ways of working demands alignment, education, and long-term commitment from senior stakeholders. As much as every client and organisation wishes, the tooling alone won’t save you!

So, where should you focus your efforts instead? Let’s explore some foundational fixes that really matter.

Product management is the lynchpin

In the complex web of infrastructure, tools, teams, and platform expectations, one role sits at the centre of it all: The Platform Product Manager. In order to have a successful Cloud Native project, their role must:

• Translate business goals into platform capabilities
• Advocate for users while managing top down pressures
• Balance short term demands with the long term platform vision
• Have a firm understanding of the technical landscape, without being buried by it

If your project lacks strong product management, your Cloud Native initiatives will drift. Your tooling will be deployed without purpose. Your platforms become ungovernable. And the trust between platform and development teams erodes.

Shift the mindset from big bang to continuous evolution

If you can achieve the mindset shift from “install and support” to “build and improve”, you will see tremendous results. After all, Cloud Native isn’t a big bang transformation, it’s a continuous evolution. In our experience, the organisations that treat their platforms as living products shaped by feedback, seek incremental improvements, strong platform principles and guided by clear goals are the ones that thrive. On the contrary, those who chase silver bullets, follow vendor hype, and treat Cloud Native change as a one-off project? They’re doomed to repeat the same mistakes every five years.

Final thought: evolve or stagnate

The core lesson from this blog we want to ensure you build into your Cloud Native project is this: “Technology alone doesn’t make you Cloud Native. Mindset, process, and capabilities do.” We’ve found that if your teams aren’t empowered, if your feedback loops are broken, if your capabilities aren’t defined, and if your product thinking is absent, then no amount of Kubernetes, Backstage, or any other CNCF product will save you.

Lastly, it’s important to remember that Cloud Native is not the final stop. It’s the beginning of building an organisation that can keep evolving.