Introduction
When legacy infrastructure is about to be switched off, there is no room for experiments, hype, or blind attempts at automated cloud migration. The system either migrates cleanly or it stops working. That was the situation behind a recent cloud migration project for a US based client, where an existing computing environment had to be moved from a decommissioned provider to a new serverless setup before hard deadlines kicked in.
This was not a greenfield rewrite. The business logic was stable, tested, and intentionally left untouched. The task was purely infrastructural. Migrate and adapt the code so it could run in a new environment, accept requests correctly, and integrate with existing gateways. On paper, it looked like a classic manual migration. Careful, slow, and expensive.
Initially, the team estimated around 130 to 140 hours of engineering work for code migration alone, plus additional time for manual setup, testing, and validation. That estimate included risk buffers, unknowns, and the reality of dealing with a large codebase and multiple services. It was a reasonable estimate, based on how similar migrations had been done before.
This time, the team deliberately chose a different approach. Instead of treating it as a conventional infrastructure task, the team approached it as a controlled AI migration initiative, focused strictly on structural translation rather than system redesign.
It is important to stress that the acceleration described below was possible only because the migration was led by a highly experienced engineer with deep understanding of the system architecture and infrastructure patterns. AI tools were used skillfully and deliberately. Without strong technical judgment and disciplined review, the outcome would have been very different.
Why this migration was a perfect candidate for AI assistance
The key constraint shaped the entire strategy. The business logic could not change. No refactoring. No redesign. No creative freedom. The goal was structural translation, not reinvention. That made the task unusually suitable for AI assisted programming.
Instead of asking engineers to manually reimplement patterns they already understood, the team explored whether modern AI models could handle the repetitive but risky parts of the work faster, while engineers stayed fully in control of review and validation.
It was a shift in how engineering time was spent.
From manual breakdowns to AI driven planning
The first experiments used Cloud Code, paired with a strong but limited model. It worked, but required heavy manual planning. Engineers still had to break the migration into small pieces, write prompts for each step, and sequence the work themselves. The AI executed tasks, but did not help structure them.
That changed with the introduction of Cursor and its planning mode, paired with GPT 5.2 Codex High. Instead of dozens of small prompts, the team wrote a single large prompt that included full context. Project structure, technologies used, similarities with previously migrated services, and explicit constraints around business logic.
The AI responded not with code, but with a detailed migration plan. A structured to do list that mapped the entire process step by step.
Facing a migration deadline? We've done this before.
This project moved from a 130-hour estimate to under two weeks, not with automation, but with an experienced engineer using AI deliberately. If you're evaluating a similar migration, we can walk you through exactly how we'd approach yours.
That plan was not executed automatically. Engineers reviewed it, adjusted it where needed, and then deliberately used it as structured input for further execution. In practice, the migration plan became a controlled script for the next stage of AI-assisted implementation.
Engineers decided which parts could be safely delegated, which model to use for each stage, and how to sequence execution. In some cases, cheaper models were used to implement clearly defined steps. In others, deeper reasoning models were involved again. Every change was validated against the original environment before approval.
AI performed structured implementation, but engineers actively orchestrated the entire process. The models executed tasks. The engineers designed the flow, supervised execution, and made all final decisions.
The impact on delivery speed
The numbers tell the story clearly.
What was initially estimated as roughly one month of manual work was reduced to a matter of days for the core code migration. Manual tasks such as environment wiring and configuration were still required, but even there, AI was used to generate detailed instructions that reduced future manual effort.
Testing and validation remained non negotiable. Nothing was deployed without review. The difference was that engineers were reviewing code instead of writing repetitive glue logic from scratch. Traditionally, we assume that around 80 percent of migration time is spent coding and the remaining 20 percent on verification. In this case, that ratio effectively flipped. AI accelerated implementation, while most of the engineering time shifted toward testing, validation, and confirming behavioral parity with the original system.
From a delivery perspective, the migration moved from a multi week effort to a process that realistically fit into one to one and a half weeks including testing and follow up tasks. Beyond engineering efficiency, this shift also strengthened the cloud migration business case. Reducing delivery time by over 90 percent changed the cost structure, lowered deadline risk, and freed up senior engineering capacity for higher value work.
It is worth noting that this particular product did not process sensitive personal data, which allowed us to avoid deep security audits or formal penetration testing during this phase. In systems handling PII, financial records, healthcare data, or other regulated information, testing time must increase significantly. AI created leverage in this context, but leverage always depends on risk profile and domain constraints.
What tools were tested and what actually worked
Several tools were evaluated during this process, each with clear tradeoffs.
Cloud Code proved reliable for daily work. Its pricing model, based on daily limits, encouraged consistent usage without the risk of burning an entire monthly quota in a few days. The downside was the lack of planning support, which made it less suitable for large-scale migrations.
Cursor stood out for complex tasks thanks to its planning mode. It allowed engineers to see the full migration plan before committing to execution. The drawback was pricing. Token based monthly limits can be exhausted quickly during intensive work, making it less predictable for longer projects.
GPT 5.2 Codex High was the most effective model for planning. It took longer to reason, but consistently produced more accurate and complete results. Cheaper models were still useful, but mainly for executing already defined steps.
One important insight emerged. Use expensive models to think, not to type. Planning benefits from deeper reasoning. Execution can be delegated to cheaper models once the path is clear.
Why this was not blind automation
The team was careful to avoid what is often called vibe coding, where AI generated output is accepted without review. That approach creates brittle systems and hidden risks.
Instead, this work followed a clear pattern. AI acted as a junior engineer, but under strict supervision. Engineers delegated tasks, reviewed every change, and validated that behavior matched the original system. The speed gains were possible because a skilled engineer used AI models thoughtfully and with full accountability. Nothing bypassed human judgment.
This distinction matters. AI assisted programming increases speed without sacrificing responsibility.
Lessons worth keeping
01
Context matters more than prompts. A large, detailed first prompt dramatically increases the chance of near one shot completion.
02
Planning is where AI delivers the most value. Let models think before they write.
03
Third, tool choice should follow task weight. Lightweight fixes and heavy migrations should not use the same models or pricing assumptions.
04
Finally, AI works best in teams that already understand their systems. It does not replace expertise, it amplifies it.
This migration did not succeed because of AI alone. It succeeded because an experienced engineer used AI deliberately, skeptically, and with clear boundaries. AI was not a silver bullet. It amplified existing expertise. That is what turns new tools into real engineering advantages, instead of another short lived experiment.
Many teams are approaching the same deadline. Legacy infrastructure is being switched off, and the window to migrate cleanly is shrinking. Whether AI-assisted programming makes sense for your migration depends on specifics — your codebase, your constraints, your risk tolerance. The right answer starts with understanding your system.
If you are facing a similar project and want an honest assessment of what is realistic, we are ready to have that conversation. Let’s talk.
