Database migration to AWS, Azure, OCI - how to recognise who was really involved

Cloud migration is more than just a move: anyone who has really migrated a database to AWS, Azure or OCI had to think about architecture, security and resilience. In this article, you will learn how to recognise real project experience in an interview - and how to expose fake responsibility.

"I was responsible for the cloud migration of our database" - sounds good, doesn't it? But what does that actually mean?
Was it a production-relevant migration with architectural responsibility, security concept, replication logic and downtime strategy - or just the execution of a script?

Database migrations to AWS, Azure or Oracle Cloud in particular very quickly reveal who has only filled one VM - and who has mastered the application logic, performance implications and business continuity.
Because migration doesn't mean: "Go somewhere else now". Migration means: New environment, new dependencies, new risks.

In this article, you will learn how to recognise within minuteswhether your candidate has really mastered this complexity - or just has the label "Cloud" on their CV.

1. cloud migration: lift & shift vs. replatforming in comparison

Two buzzwords that are often used interchangeably - but are fundamentally different.

At the Lift & Shift the existing database is moved almost 1:1 to the cloud. Technically often through tools such as:

• pg_dump / pg_restore for PostgreSQL: a command line tool that writes database content to a dump file and restores it - simple, but without regard to latency, application availability or index strategy.

• expdp / impdp with Oracle: export/import at file level - effective, but no real platform transformation.

Such an approach often runs without major changes - but also without architectural responsibility.

At the Replatforming In contrast, the database is transferred to a new, cloud-native platform: e.g. from Oracle On-Prem to PostgreSQL in AWS Auroraincluding the customisation of stored procedures, indexing, performance monitoring and often also the IAM concept.
Who from Schema conversion, trigger rewriting, use of read replicas and Automated backups was much more deeply involved than someone who only moved dumps.

A clear indicator: If you can't hear in the interview, what has been changed specifically - it was not true replatforming.

2. who decided - and who was only allowed to participate?

Migration projects are never purely technical endeavours. They always also affect compliance, operating costs, availability and often even entire licence models.
So the crucial question is: Who was involved in the strategy?

Anyone who cannot categorise the following terms was not part of the architecture or decision-making phase:

• RTO / RPOHow much data loss is tolerable? How quickly must a system be back online?

• Cloud governance modelWere there any specifications regarding access rights, multi-client capability, data storage?

• Business CaseWas it about reducing licence costs (e.g. "Get out of Oracle"), consolidation or strategic cloud use (e.g. integration with Data Lake)?

Important differentiation: Part of a project team ≠ Part of the control system. Cloud migration

3. understanding roles: Architect, DBA, Project Manager - who really did what?

If someone says: "I was responsible for the migration", you should be more specific:

• If the person has developed the target architecture?

• Was it for the IAM concept responsible?

• Has she written Terraform modules for provisioning?

• Or was it primarily Coordinator of service providers?

Anyone who has really been deep inside can describe it:

• How the target systems were sized (CPU, memory, IOPS)

• How fail-safety was designed (e.g. Azure Availability Zones vs. AWS Multi-AZ)

• How secrets and access data were secured (e.g. with Azure Key Vault or AWS Secrets Manager)

Only those who can explain all this have not only accompanied migration - but are responsible for it.

4. reliability - was it planned or just claimed?

"Of course, we paid attention to high availability."
But what does that mean? Cloud migration

Anyone who has taken the topic seriously can describe:

• Which backup strategy was used (point-in-time recovery? snapshots? archiving in Glacier?)

• How disaster recovery was planned (different region? different account? cold standby?)

• Whether failover scenarios tested or only existed on PowerPoint

A warning sign: When someone says "monitoring" but doesn't use tools like CloudWatch, Azure Monitor or OCI Metrics then there was probably no real operational concept.

5. interview questions that those responsible can answer - and others cannot

If you need clarity quickly in the interview, ask these questions:

• How exactly was the database migrated - tool, format, downtime?

• How was the application prepared - were there dual writes, freeze phases, delta sync?

• Who defined the target environment - and how?

• Which security policies have been defined for database access?

• Were there automated deployments - and with which CI/CD tool?

And very specifically: What was the most difficult moment in the migration - and how was it resolved?

Anyone who answers specifically was involved. Anyone who cancels or evades was only there.

🎯 Download: Interview questionnaire database migration (PDF)

20 professional questions - 10 each on migration responsibility & resilience
Use our template to find out reliably in an interview or screening:

• Who was jointly responsible for architecture, platform selection and security

• Anyone who has planned (and implemented) downtime, disaster recovery and backup processes

Want to know who really did a cloud migration? We can help you.

Database migrations to AWS, Azure or OCI are not standard jobs - they require a deep technical understanding, precise role clarity and real delivery expertise.

If you want to fill such roles, we will support you not only with qualified candidates, but also with:

• Technical evaluation of real project experience

• Precise interview questionsthat make the difference

• Deep dives into tools, platform logic and security concepts

👉 You don't want to guess, you want to know? Then talk to us. We'll find those who don't just say "Cloud" - but have actually made Cloud.