Most businesses who have thorny old systems will know by now that getting them off legacy hardware and onto much cheaper and more flexible cloud-based systems is probably smart.
What you might not know is that moving such a system on its own could be a missed opportunity to modernise. But isn’t modernising the act of moving from old local hardware to the cloud?
Well, in a sense. It’s a move from old tech to new, yes. But lifting an old system and plonking it on a new cloud is a long way short of true modernisation. If you take the engine out of an old car and place it a new car’s body, that’s an improvement of sorts. But the car won’t be any more fuel efficient than it was. Any problems the engine caused in the old car will still be present in the new one. However nice the new car might feel, it’s still using an old, inefficient engine that might need to be replaced sooner rather than later.
This isn’t to say that you should throw everything in the bin and start from scratch. After all, maybe there’s nothing wrong with the stereo or the wheels (you certainly don’t want to reinvent those too often).
So while it might be appropriate to go back to the drawing board sometimes, it would be a big waste of money if every modernisation project were simply a complete rewrite from first principles.
Application modernisation might not be what you think
A well-used phrase in this area is application modernisation. It sounds fancy and progressive but the term could be misleading. It’s also referred to as the less glamorous lift and shift, which is a more realistic description of what it is: a basic move from on-premises machines in local data centres over to virtual machines in the cloud. Such work doesn’t involve any refactoring or real optimisation. Instead, it’s based on repeatable processes, especially for larger applications.
A business offering such a supposed modernisation service doesn’t need a deep understanding of how an existing system and its applications work. There’s little to no requirement for software development, software engineering or hard thinking. With a low technical barrier to entry, hundreds of consultancies and contractors can offer such a basic moving service, leading to commoditisation (essentially making this a low-value, off-the-shelf purchase).
At 345 Technology, we refer to this as “moverisation“. It’s definitely not the same as modernisation in any meaningful way. This approach has no impact on how applications work, only on how they’re fed and watered (via the cloud versus via local data centres).
Beware of moverisation
Lots of providers may be able to move on-premises systems to the cloud, but comparatively few can do that with a deep enough understanding to truly modernise and optimise those systems.
Lift and shift providers may call themselves cloud experts or experts in digital transformation. They may even be a Microsoft Gold Partner with the Cloud Platform competency, and be a MSP. These titles sound fancy, but in reality a rather basic lift and shift might be the majority what they do.
This isn’t us. We’re far more considered about our software projects, and we look to do things that set up our clients with competitive, up-to-date systems. This requires an understanding of the code, which leads to more optimal systems that run better and that make best use of the cloud. For example, our analysis might lead us to recommend using a cloud PaaS to shift the operational onus to the cloud provider, which could lower the running costs for an app.
So, is modernising more expensive than just “moverising”? Well, yes, but only if you think in the short term. The other view is that it’s an opportunity for businesses to strengthen their offering and become more competitive – and how much might that be worth down the line? If your competitors are busy strengthening and you’re counting the pennies by doing only lift and shift moves to the cloud, you might be left behind.
True modernisation doesn't have to apply to your whole system
As with the car analogy, it might not always be wise to try to modernise every single bit of your old systems. Perhaps some parts work perfectly adequately and are in no need of attention, in which case a basic move to the cloud will be adequate for those parts.
We’ve found that the Pareto principle applies when working on modernisation projects. This means that 20% of your system setup may be responsible for 80% of the value that the system offers your business.
To give you the maximum bang for your buck, we focus on what that most valuable 20% is so that we can deliver a modernised setup that gives you better returns and that is significantly quicker to implement than if we had attempted to modernise the whole thing.
Potential problems with lift and shift alone
In some cases, the cheaper lift and shift approach may not be feasible as some applications may not work the same way on the cloud. In such circumstances, lift and shift providers would not have the understanding and skill to achieve what their clients want.
A failure to modernise could lead to some unwanted outcomes:
- You’re left with old or legacy monolithic applications that have no DevOps support: these will need to be modernised or replaced eventually, and what then?
- Your team takes ever longer to deploy, test, release: meanwhile, your competitors with optimised systems can innovate much faster.
- Your most critical or valuable applications may be the most problematic when moved to the cloud: a simple lift and shift to the cloud may mean your apps don’t do what you already expect them to, affecting your BAU processes.
How we approach true modernisation
As part of a modernisation and improvement, we pull apps and systems apart and break them into smaller maintainable chunks. Because we build apps and put them together – we’re solution architects who are application focused – we’re also best placed to deconstruct them, understand how they’re currently built and then put the pieces back together in a smarter way.
Refactoring is the progressive route to optimising performances and efficiency. It involves changing the design of the software and the way its internal pieces fit together, without necessarily changing the way it works. Developers do this all the time, continually refactoring their designs to produce optimal results. Legacy apps have often not had this cycle of improvement for many years. This is almost like evolution being frozen for long periods. The applications that can’t “adapt to their environment” will eventually become extinct.
Our deep understanding of applications and code has set us apart and means that the projects we work on produce systems that are relevant and competitive (in other words, our software outputs won’t become extinct any time soon).
