The Migration Takes 2 Weeks. Deciding to Do It Takes 6 Months. (Webinar Replay)
Replay and recap of our October 20 live session: why the decision to migrate takes longer than the migration itself, the five human blockers behind it, two customer migrations, and three ways to cut decision time. Chapters, timestamps and key takeaways.
In our October 20 live session, Guillaume Da Silva, Staff Solutions Architect at Qovery, looked at the months before a migration starts, which rarely make it into the project plan. Guillaume spent twelve to thirteen years running migrations to AWS and GCP for an AWS partner before joining Qovery. In his experience, the technical work is the smaller part, and most of the time goes to people deciding to move. Romaric Philogene, CEO and co-founder of Qovery, co-hosted and asked the questions leadership teams ask before they approve a migration.
This page has the full replay, a chapter list and the key takeaways. Every section links to the exact moment in the video.
The decision takes longer than the migration. In Guillaume's experience, the technical work is about 20% of a migration. The rest is people deciding, planning and waiting.
Five human blockers explain most of the delay: the one-way door feeling, no one to do the work, fear of the unknown, value you can't see right away, and not trusting whoever will do it.
Teams often wait for an incident. One customer said no after a 12-week evaluation, had two incidents, then came back. The migration itself took 5 days.
Make it reversible, make it cheap to prove, and move in waves. Keep the old stack running, prove the target in an afternoon, and move the database last.
Being slow costs more than being wrong when the move is reversible.
Guillaume splits what delays a migration into two tracks.
The technical track is the one everyone plans for. Through many AWS Migration Acceleration Program (MAP) projects, it always looked the same: assess what you have, run discovery on the infrastructure, take over infrastructure as code that nobody fully knows any more (old Terraform, Pulumi, technical debt), rebuild the CI/CD workflows that put applications into production, then validate data and behavior on a staging platform. In his experience that is about 20% of the job, done by technical people (watch at 07:54).
The human track is the rest. People take time to decide, fear the change, or don't see the value of the migration (watch at 09:23).
It feels like a one-way door. Nobody wants to go back to the old infrastructure, so every migration "has to" succeed, because a rollback costs a lot of money and time.
No one is available to do it. A migration needs a sponsor and dedicated people. You can bring in a service company, but if your team is not part of the work, the knowledge leaves with the contractor and you end up buying managed services to run infrastructure you no longer understand (watch at 10:08).
Fear of the unknown. The cloud is no longer new, but integrating AI into infrastructure is the new unknown (watch at 16:15).
The value isn't visible right away. While your team migrates, it isn't building product. Guillaume's advice is to look at the ROI over one or two years and to count the cost of doing nothing: what you lose today, and why your competitors move faster (watch at 17:04).
Trust in whoever does it. Adopting a tool means adopting the team behind it.
An attendee asked how much of this comes down to documentation. Guillaume said only partly. Documentation is never fully up to date, and neither are people. In a large migration, every person holds part of the knowledge, so discovery means sitting down with the infrastructure, network, Windows and Linux teams to put it back together. Romaric added that keeping documentation current can now be largely automated, as long as someone reviews it.
Romaric asked how to get past the mindset that a legacy system works, so nobody should touch it. Guillaume's projects were mostly in finance, a regulated sector that moves slowly. What convinced them was competition. Online banks were moving faster, and staying on legacy infrastructure put the business at risk.
Both customers are under NDA, so no names or dates.
Customer 1: 12 weeks to decide, 5 days to migrate
A European B2B SaaS company with 20 developers and one person managing the infrastructure. The evaluation, from proof of concept to the first staging environment, lasted 12 weeks. At the end, the team decided it didn't need Qovery. Then it had two incidents that the infrastructure Qovery runs would have prevented, and came back (watch at 18:57).
Once the decision was made, the migration from ECS to EKS took 5 days, with Qovery's MCP server and agent skills handling discovery, wave planning and the migration itself. A few years earlier, the same team had moved from Heroku to ECS by hand, with one person and no AI. That took 3 months (watch at 20:05).
Guillaume, who has run marathons, compared those 12 weeks to a full marathon training plan, time the team spent waiting for the next incident.
Romaric pointed out how often this happens. Teams know they have to modernize, but the cost of not doing it stays theoretical until something breaks. That is why Qovery asks early what waiting costs, so the number is on the table before an outage puts it there.
Customer 2: staging in one afternoon, 7 weeks to decide
A US scale-up running a multi-tenant application, with three engineers and no DevOps or infrastructure person. During the kickoff meeting, the CEO started using the Qovery skills on the spot. By the end of the afternoon, the infrastructure was ready and staging was deployed.
Even so, the team took 7 weeks to decide. They were already on AWS and ran the infrastructure themselves, so they did not see how much time maintaining it cost them. Time spent on infrastructure is time not spent on the product (watch at 25:35).
What made the decision easier was keeping the old infrastructure running. If anything went wrong, they could switch DNS back to the previous stack: no service interruption for their customers and no rollback work (watch at 27:18). It worked, and their production still runs on Qovery. Staging took one afternoon, production the rest of the week. The database was already on RDS, so the new environment connected to it directly.
Prove your migration target in an afternoon.
Spin up a staging environment on Qovery in your own cloud account, keep your current stack running, and decide with real data instead of slides.
One-way door: keep the old stack as a way back. Build the new infrastructure as a preview or staging environment, validate it, then promote it to production.
No one to do it: delegate the migration work to an AI agent. Qovery brings the guardrails: the agent works through an API with the permissions you give it and does not delete resources.
Fear of the unknown: a platform lets you get something running in a few hours, so you can test the target before you commit.
Value not visible: count the cost of waiting, from performance, cost and security on the old stack to competitors who move faster.
Trust: ask for case studies and references. Qovery publishes case studies, works closely with AWS, and can connect you with CTOs and heads of engineering who already made the move.
Romaric described a recent visit in Los Angeles to a customer who moved to Qovery three years ago and had just spent time with another company's VP of Engineering, talking openly about how it works. Even when the team is convinced by its own tests, leadership needs to know the platform will still work in the years ahead.
Guillaume added that software will fail one day. When it does, the team behind it matters, so challenge the support and onboarding teams before you choose (watch at 34:46). Romaric agreed, and listed what infrastructure buyers remember: response time, transparency when something goes wrong, and the work done so it does not happen again.
Once the decision is made, the technical work (assessment, discovery, taking over CI/CD pipelines and infrastructure as code) can largely be delegated to AI. For the first customer, Qovery deployed the cluster in about 20 minutes, generated and maintained the landing zone layer, and sped up the container deployments, while agents handled discovery and migration prep. Humans validated every important step: the cutover and the database migration in particular, because there is no second chance there.
Guillaume's point was that a first environment can run within an afternoon, so testing performance and security on the target costs a few hours of infrastructure and some tokens. For the same idea before AI agents, Romaric's earlier article covers how 37 apps moved from Heroku to AWS in under two hours. Guillaume also noted that AWS is moving the same way, bringing its migration tools together into one AI-assisted product, AWS Transform (watch at 40:42).
Even with that much automation, customers want a technical person they can talk to. Guillaume gets two or three support tickets a week from customers pasting an AI answer and asking him to check it.
Instead of a live migration (the previous session covered that), Guillaume walked through Qovery Training, a sandbox copy of the Console on fake data. He picked the Heroku to AWS track with a Rails, PostgreSQL, Redis and Sidekiq stack and showed:
Organizations, projects and environments, and ephemeral environments created for each pull request (watch at 45:30)
How the agent maps a Heroku app: dynos, workers and databases become Qovery applications and databases, images are built and pushed, and everything deploys with its environment variables (watch at 46:56)
Sizing and scaling: CPU, memory and GPU per service, autoscaling with HPA or KEDA, and variables moved from the old platform, with database credentials handled by Qovery as secrets (watch at 48:04)
Preview environments, the equivalent of Heroku review apps, which agents can also use to test changes on real infrastructure before production (watch at 49:56)
You can try Qovery Training yourself. It needs no cloud account, and nothing you do there touches real resources.
Make it reversible. Keep the old infrastructure running so you always have an exit. This is easiest when moving between platforms like Heroku, Vercel or Render, and harder on-premises, where less runs through APIs.
Make it cheap to prove. Pick a target where a first pilot application runs in a day or a few days, and check performance, security and data governance yourself.
Split the migration into waves. Platform first, then applications, and the database last. If an application misbehaves, you can bring it back while the database still runs in the old environment.
Guillaume closed with a principle from Jeff Bezos's 2016 letter to Amazon shareholders: most decisions should be made with about 70% of the information you wish you had. When the move is reversible, being slow costs more than being wrong (watch at 55:48).
Let the platform and the agent do the migration work. Spend your people on the plan and on what carries real value, such as the database.
Make it reversible. Keep the old infrastructure, move the hardest part last, and start with pilot applications so your team builds expertise before production moves.
Start the decision on day one. It is the longest part, so the sooner it starts, the sooner you migrate.
What's next
Our next session, in five to six weeks, covers migrating from ECS to EKS. The date will be on the events page soon.
Questions after watching? Talk with us and we will connect you with the team, or with a customer who has made the same move.
Frequently asked questions
How long does a migration take?
In Guillaume's experience, the technical work is about 20% of the total time. In the two customer examples, the migration itself took 5 days and less than a week, while the decision took 12 weeks and 7 weeks.
How do I reduce the risk of a migration?
Keep the old stack running so you can switch DNS back, validate the new infrastructure in a staging or preview environment first, and move the database last.
Can an AI agent run the migration?
An agent can handle discovery, planning migration waves and deploying the services, within guardrails. Keep a human on approvals, the cutover and the database migration.
What if my team has no DevOps engineer?
The second customer in the session had three engineers and no infrastructure person. Qovery runs the platform layer in their AWS account, and they had staging deployed in one afternoon.
Romaric founded Qovery to make Kubernetes accessible to every engineering team. He writes about platform strategy, developer experience, and the future of cloud infrastructure.
Next step
Prove your migration target in an afternoon.
Spin up a staging environment on Qovery in your own cloud account, keep your current stack running, and decide with real data instead of slides.
