How to migrate Oracle to AWS, and how to choose the target
The difficulty of an Oracle migration is set by where you are going. Staying on Oracle and moving to a different engine are two different projects with two different checklists.
This page is for teams that want to move on-premises Oracle to AWS but have not yet narrowed the target options. GIIP has migrated an on-premises Oracle environment with approximately 120,000 tables to AWS, and handles environments with extreme object counts.
Too many target options
Stay on Oracle, or move to another engine? You have nothing solid to decide with.
The volume of PL/SQL is unknown
Stored procedures and packages hold business logic, and it is unclear how much of it can move.
The inventory never finishes
With that many tables, views, synonyms and triggers, even producing the list of what must move is an unfinished project.
Each target carries different premises
Staying on Oracle makes licensing and topology the issue; changing engine makes SQL and PL/SQL rewriting the issue. The same phrase "AWS migration" describes two different jobs.
Dependencies are buried in business logic
The longer an environment has run, the more business judgement sits inside triggers and packages. Each one is a decision: move it, or lift it out.
You cannot estimate what you have not counted
With a high object count, no mechanical extraction means no defensible estimate at all.
Before laying out options, establish the scale and the dependencies mechanically.
Mechanical object inventory
Extract tables, views, synonyms, stored procedures and triggers per schema, producing both the scope list and the evidence that it is correct.
Frame the target options
From the volume of PL/SQL, licensing terms, external integrations and required availability, present the realistic options and their trade-offs.
Design the verification
Make before/after reconciliation of counts, definitions and dependencies something a machine runs across the whole scope.
What you can check yourself first
- Oracle version and edition
- Number of schemas and approximate table count
- Rough volume of stored procedures and packages
- Database links and integrations with external systems
- Number of batch processes and when they run
- Terms of your current licence agreement
- How many hours the business can be down
What we can evidence
The specific AWS service configuration used as the target is beyond what has been confirmed and is not published. Customer names and business data are likewise withheld.
Frequently asked questions
Should we keep Oracle on AWS?
The more business logic lives in PL/SQL, the lower the migration risk of staying on Oracle — but the licence cost stays too. The choice is as much a contractual decision as a technical one.
What makes a high table count a problem?
Not the migration itself, but proving the scope is complete. Manual inventory does not finish, so extraction and reconciliation have to be automated.
Is 120,000 a record count?
No. It is a table count — not records and not databases.
What will it cost?
It varies with scale and breadth of dependencies. We do not quote figures we have not established. The factors that drive cost are set out on a separate page.
How to migrate SQL Server to AWS, and what to check first
Check for free whether your database can be migrated Migration checklistLarge-scale database migration checklist — what to settle before you start
Check for free whether your database can be migrated Database migration costWhat actually determines the cost of a database migration
Check for free whether your database can be migratedCheck whether your Oracle environment can be migrated
Tell us the version, number of schemas, approximate table count and external integrations.