When a client asks us to move a system to AWS or Azure, an assumption usually rides along with the request: that everything should be re-architected on the way across. Microservices, containers, serverless, the full set.
Sometimes that is right. More often it quietly converts a migration into a rewrite, and rewrites are where timelines go to die.
Move it, then improve it
Lifting a working system onto cloud infrastructure with minimal change is unfashionable and frequently correct. You get out of the datacentre, you gain elasticity and managed backups, and you start generating a monthly bill that tells you precisely which parts of your system are expensive.
That bill is far better prioritisation input than an architecture diagram. Optimise what is costing money, not what looks untidy in a drawing.
What genuinely should change first
A few things are worth fixing during the move rather than after it: secrets sitting in config files, backups nobody has ever restored from, and any single point of failure you can already name. All three are cheap to fix in transit and painful once the system is live somewhere new.
Containers are not the goal
Containers are a packaging decision, not an outcome. If a team is not yet running reliable CI, and nobody on it can debug a cluster at two in the morning, Kubernetes adds risk rather than removing it. Start with managed services. Adopt orchestration when the thing constraining you is genuinely orchestration.
Sizing for peak, paying for average
The real financial argument for cloud is not that it is cheaper, because often it is not. It is that you can size for your busiest hour without buying hardware that sits idle for the other twenty-three.
Written by the Prakmas team, Hyderabad and Union City.
All insights