Spend enough time in pre-sales for cloud projects and you notice the same fork showing up in almost every conversation. A customer has a system that’s creaking. The question on the table is whether to modernize what they already have or start fresh with something built for where they’re going.
It’s tempting to answer with technology. Lift-and-shift, re-platform, re-architect, go serverless. But I’ve learned that leading with the technology is how you end up solving the wrong problem beautifully. The good answer starts with discovery, and discovery starts with questions.
What I’m actually trying to find out
Before I have an opinion on modernize-versus-greenfield, I want to understand a few things honestly:
What’s the business actually trying to do? Not “the system is old,” but the outcome. Faster releases? Lower cost? A new product line the current stack can’t support? The outcome quietly decides most of the architecture.
What’s genuinely broken, and what just feels old? Plenty of systems are unfashionable but completely fine. Replacing something that works is an expensive way to feel modern. I want to separate real pain from aesthetic discomfort.
What’s the cost of change — including the people? A greenfield build can be the cleaner answer on paper and the wrong one in practice if the team can’t operate it. Readiness is part of the design, not an afterthought.
What can’t move? Compliance, data residency, an integration nobody fully understands anymore. The constraints are usually where the real solution hides.
How the two paths tend to play out
Once those answers are on the table, the recommendation gets a lot clearer. The way I think through it usually looks something like this:
Modernization tends to win when the core logic is sound and the pain is operational: scaling, cost, slow deployments, fragile infrastructure. Moving to managed services, containerizing, peeling off the worst bottlenecks piece by piece. It’s lower risk, and the customer keeps running while it happens.
Greenfield tends to win when the constraints of the old system are the actual problem, or when there’s something genuinely new to build. A blank page is freeing, but it’s also a bigger commitment, and I try to make sure the customer is choosing it for the right reasons rather than for the relief of not dealing with legacy.
Most real engagements land somewhere in between: a new core, a few old pieces kept on purpose, a migration plan that respects what’s already working.
Where AI has changed the work
The discovery itself moves faster than it used to. I use AI to pull together research on a customer’s industry before a call, to summarize long requirement threads into something I can actually act on, and to draft first-pass proposals and option comparisons that I then sharpen by hand. It doesn’t replace the judgment. It clears the busywork so there’s more room for the judgment.
That’s also a big part of what pulled me toward learning the cloud properly. I’ve spent a lot of time scoping what should get built. The more I understood the tooling underneath, the better my questions got, and the better the solutions on the other side of them.
The short version
Modernize or start fresh is a technology question wearing a business question’s clothes. Ask what the business is trying to do, what’s truly broken, what it costs to change, and what can’t move. The right architecture usually falls out of honest answers to those. The tech is the easy part once the problem is clear.