Most organizations moving to cloud today are starting from the same place: on-premise applications that were built years ago, by engineering teams who have long since moved on. Before any decision gets made about how to migrate, whether to rehost, replatform, or fully rearchitect or even fully reimagine, the first step is always discovery. Go into the environment, understand the infrastructure and understand the application architecture. That’s where things get complicated, because what’s left is usually just the source code, and it tells the story of what the system was designed to do. It doesn’t tell the story of what it’s really doing today. In my experience, those two things frequently aren’t the same.
The Reverse Engineering Problem, Solved
Reverse engineering legacy systems used to be an entirely manual process. The documentation, if it existed at all, may have been written 30 years ago and can no longer be depended on. The SMEs who built these systems have often moved on, and finding engineers who can interpret older technology stacks is genuinely difficult. Going through millions of lines of code by hand would take years to do meaningfully.
What AI has done is automate that process. It can look directly at the source code, understand the codebase, figure out which component is dependent on what, and identify which code is being used today versus what was written years ago and no longer applies. But the piece that changes the analysis most is production log analysis. AI can look directly at the production logs and figure out what is truly happening in the application. Even if the system is essentially a black box, AI takes a torch and looks for the areas that need to be opened, and it does this at a scale that simply wasn’t possible before.
From that analysis, we can build the dependency graph and set the wave planning (which components to address first and in what sequence). That’s the reverse engineering side. Forward engineering follows: agentic workflows generate user stories from the technical documentation and dependency analysis, map them to the target architecture, apply the appropriate design patterns, produce a design document, and generate functional source code and unit tests. That output goes into the developer’s IDE, where engineers take it to a final working version. The architectural judgment—what to build, how to validate it, where the generated output needs correction—stays with the engineers throughout.
The Business Case for Refactoring
After discovery, the options for how the application can be hosted in the cloud come into view. Some are candidates for rehosting, taking the application as-is with minimal changes. Others suit replatforming, where the underlying infrastructure becomes a managed service without touching the application itself. Some need the full rearchitecture and in some cases even full reimagination; if the application is monolithic and there are enough reasons to break it into microservices, we identify which decomposition patterns apply, complete the rearchitecture or reimagination, and move to cloud-native services.
Rearchitecture or reimagination is where the most friction surfaces. From a business perspective, it can look like a technology exercise with no new features and nothing visible to the end user. The business might say they’re not getting anything new out of it. The value proposition has to be clear: go-to-market speed, issue resolution, and cost.
- Go-to-Market Speed
A feature that takes four weeks to ship through a monolithic deployment cycle can move in two weeks once the system is decomposed. One component gets touched, deployed, and shipped; quality engineering is scoped to that component rather than the entire application, and that compression applies to every release going forward. - Issue Resolution
When production bugs or outages occur, microservices make them much easier to handle because different components can be scaled individually. If the pricing processor is the bottleneck at peak load, that’s the only service that needs to grow. - Cost
Cloud is always OpEx, teams pay for what runs. When a monolith scales, everything scales. In a microservice architecture, the component under pressure scales, and the overall cost implication is considerably lower.
These are indirect benefits. They don’t show up as new product features, but they’re quantifiable in dollar numbers, and that’s how the business case gets made.
The Real Cost of Staying Put
Keeping an application on-premise means letting go of flexibility. Any new feature addition hits bottlenecks. Auto-scaling, the kind configured in advance based on user load and concurrency parameters, isn’t something teams get out of the box. Instead, engineering teams end up in a reactive mode: spending sleepless nights figuring out why the application is not performing under load. And when a new server needs to be provisioned, it means going through a convoluted process and waiting two to three weeks. Resources that could be focused on business-critical work get consumed by infrastructure management and outage response; that trade-off is often underestimated until the cloud migration is completed.
Cloud Portability Challenges
I keep seeing the same pattern: standardization challenges across hyperscalers. They offer equivalent service categories: relational databases, NoSQL, and containers. But there’s a lack of a cross-industry standard for how those services are configured and operated, so moving from one hyperscaler to another may consume a significant time unless it is designed for portability from the get-go.
Right now, two hyperscalers control the large majority of market share, but GCP, OCI, Alibaba, and Digital Ocean are all expanding. AI is helping in this area too and making portability easier; porting from one cloud to another is more tractable today because of what AI can automate in the analysis and migration process. With the right standards and governance in place, it should be far more seamless. I expect there to be a renewed industry focus on creating those standards, and that AI will play a meaningful role in getting there. For engineers building cloud architectures today, designing for portability early (avoiding lock-in to one particular hyperscaler) is the more durable approach.
Getting the Foundation Right
The decisions made at the start of a migration have consequences that play out over the years. The quality of the discovery work, the dependency graph, the wave planning, the understanding of what the system is truly doing at runtime, is what grounds those decisions. AI has changed how deep that analysis can go, and how quickly teams can get there. The engineers who understand both the legacy system and the target architecture are the ones who take it across the line.
About Author
Goutam Mukherjee is Sr. Director – Platform Engineering at Ascendion, where he architects and delivers cloud migration, application modernization, and agentic AI engineering solutions for enterprise clients across healthcare, automotive, travel and hospitality, high-tech and life sciences. Prior to Ascendion, he served as a Solutions Architect for a global organization and its network of agencies, where he led the design and implementation of mission-critical cloud and integration platforms. He is a regular contributor to industry standards initiatives and a trusted advisor to C-level leaders navigating enterprise architecture transformation.
