Lift and Shift vs Rebuild: Two Roads to the Cloud
Imagine you are moving house from Kayole to Kitengela. Option one: hire a lorry, throw everything in, including the sofa with the broken spring, and arrange it exactly as before in the new house. Option two: sell most of the old stuff, buy furniture that actually fits the new rooms, and arrive with less. Both get you to Kitengela. One is quicker today, the other is nicer to live in. That, in a nutshell, is the choice at the heart of legacy system modernisation in Kenya: lift and shift, or rebuild.
What "lift and shift" means
Lift and shift means taking your existing software, roughly as it is, and running it on cloud servers instead of the machine in your office. The code barely changes. You gain better hardware, reliable power, easier backups and access from anywhere.
It makes sense when:
The software works well and people are happy with it
You need to get off failing office hardware quickly
The budget or timeline does not allow a rebuild right now
The system is due to be replaced in a year or two anyway
The downside: you carry every old problem with you. If the system was slow, clunky or only worked in one ancient browser, it will still be slow, clunky and fussy, just in a nicer building. The broken sofa spring is now in Kitengela.
What "rebuild" means
Rebuilding means redesigning the system for the cloud and for how your business works today. That could be a complete rewrite, or a gradual replacement where new modules take over from old ones piece by piece.
It makes sense when:
The old system is holding the business back: slow, error-prone or impossible to change
Nobody left in the company fully understands how it works
You need features the old system cannot support, like mobile access, M-Pesa integration or an API for partners
Security updates are no longer available for the technology it runs on
The downside: it takes longer, costs more upfront and needs careful management so the business keeps running during the change.
A legacy system modernisation checklist
Before choosing, sit down with the people who use the system every day, not just the ones who sign the cheques. Ask:
What do people love about the current system, and what do they work around?
What breaks most often, and what does it cost us when it does?
What will the business need in three years that the system cannot do?
How much of our process lives in the software, and how much in someone\'s head?
Njoroge, who runs a mid-sized hardware business, discovered that his staff kept a separate spreadsheet for half of what the old system was supposed to do. That told him everything: there was no point lifting a system people had already quietly abandoned.
The middle road
It does not have to be all or nothing. A common approach is to lift and shift first, to get off risky hardware, then rebuild the most painful parts over time. Another is to keep the old system for back-office records while building a new customer-facing app on top. The key is having a plan, so a quick fix today does not become a permanent compromise.
Choosing your road
There is no universally right answer, only the right answer for your budget, timeline and ambitions. If you would like an honest assessment of your current system and both roads, explore our software development services or talk to Philsoft. We will tell you if lift and shift is enough, even though rebuilding is the more fun job for us.