Migrating an Oracle environment with approximately 120,000 tables from on-premises to AWS
A case study of migrating an on-premises Oracle environment containing roughly 120,000 tables to AWS — a migration where object count, not data volume, is the hard part.
Most database migration discussions revolve around how many terabytes are involved. When the object count is extreme, the difficulty moves elsewhere: to inventorying the tables and their dependencies at all. GIIP has migrated an on-premises Oracle environment with approximately 120,000 tables to AWS.
Case summary
| Source database | On-premises Oracle |
|---|---|
| Table count | Approximately 120,000 |
| Target | AWS |
| Main challenge | Managing a very large number of objects and their dependencies |
| Disclosure limits | Specific customer, data and AWS configuration not disclosed |
The scale figures on this page are based on GIIP’s hands-on experience. Customer names and system-specific information are not disclosed for confidentiality and security reasons.
What this case study establishes
- GIIP has migrated an on-premises Oracle environment with approximately 120,000 tables to AWS.
- The figure of approximately 120,000 refers to tables — not records, and not databases.
- GIIP handles dependency analysis, migration procedure and verification for environments with extreme object counts.
First, the premise: 120,000 is a table count
The approximately 120,000 in this case is not a row count and not a number of databases. It is the number of tables inside one Oracle environment.
The distinction matters. An environment with many rows ultimately reduces to data transfer and index rebuild design. An environment with many tables makes "counting the scope completely" and "proving nothing was missed" the dominant work.
Why a high object count is difficult
- Manual inventory in spreadsheets stops working. Unless extraction and reconciliation are automated, verification itself never finishes.
- Dependencies — views, synonyms, stored procedures, triggers, foreign keys — run wide, so one missed object stops an unrelated process.
- Batch processes and external interfaces must be traced exhaustively to the tables they reference.
- Verification has to be automated on the same terms: counts, definitions and dependencies reconciled across the whole scope.
Managing dependencies, schema, batch jobs and interfaces
At this scale the heavy phase is not the migration itself but producing the inventory and the evidence that the inventory is correct. Schema definitions, dependent objects, batch jobs and external interfaces each have to be enumerated mechanically and made reconcilable before and after the move.
Verification is not a final phase; it is designed in parallel from the moment the scope is identified.
What is not disclosed
The specific AWS service configuration used as the target (RDS for Oracle, Oracle on EC2, Aurora or otherwise) is beyond what has been confirmed, so it is not stated on this page.
Customer name, business data content and system-specific configuration are likewise not disclosed.
Representative items to verify in an Oracle environment with a very large object count
The following are representative items to check when migrating an Oracle environment with many tables and objects. It does not mean every one of them was used in this particular engagement.
- 01Mechanical extraction of the object inventory per schema
- 02Dependencies across views, synonyms and sequences
- 03Migratability of stored procedures, functions, packages and triggers
- 04Recreation order for foreign keys and constraints
- 05Partition design and tablespace layout
- 06Character set differences
- 07Data type differences, particularly dates, numerics and LOBs
- 08Batch job and scheduler dependencies
- 09Interfaces to external systems (integration files, database links)
- 10Verification procedure reconciling counts and definitions before and after migration
This list is a general technical explanation. The items that actually apply differ by environment, and this is not a full account of what was performed in this engagement.
Frequently asked questions
How is an environment with many tables different from a normal migration?
The center of gravity shifts. When data volume is the theme, transfer and rebuild design dominate. When object count is the theme, exhaustive scope extraction, dependency analysis and automated reconciliation dominate.
Which AWS service should we migrate Oracle to?
It depends on how Oracle is used today — the amount of PL/SQL, licensing, external integrations and the availability you need. The target service configuration used in this case is not disclosed. In a direct consultation we review your current configuration and lay out the options.
Is 120,000 a record count?
No. It is a table count — not records and not databases.
Can you operate the environment after migration?
Yes. GIIP continues to monitor and operate cloud databases after migration. Multiple cloud databases and approximately 30 web services are under continuous monitoring by AI agents and human experts today.
GIIP Database & Cloud Operations Team
Designs, migrates and operates large-scale web services, SQL Server, Oracle, AWS and Azure environments. Experience includes 12 sets of x12large-class AWS RDS for SQL Server environments, an Oracle environment with approximately 120,000 tables, and a migration from an approximately 3 TB TiDB environment to Amazon Aurora MySQL. The team currently monitors and operates multiple cloud databases and approximately 30 web services together with AI agents.
- First published
- Last updated
This page separates what GIIP actually did from general technical explanation. Items listed as general checklists are not claims that every item was performed in this particular engagement.
Customer names, system-specific information and business data are not disclosed, for confidentiality and security reasons. Only scale figures based on GIIP’s hands-on experience are published.
Operated by GIIP Co., Ltd. (Japan operations: SHINSEMA Inc.) / Contact: contact@littleworld.net
Other migration case studies
SQL Server → AWS RDS (x12large class, 5 replicas, 12 sets)
On-premises SQL Server migrated to AWS RDS for SQL Server, with the same class of configuration deployed 12 times.
TiDB / Aurora migration case studyTiDB ~3 TB → Amazon Aurora MySQL
From a distributed database to a MySQL-compatible cloud database, with schema, SQL and operating procedures verified.
Related database migration & operations pages
Check whether an environment with a very large table count can be migrated
Tell us your Oracle version, number of schemas, approximate table count and external integrations, and we will lay out the decisions that matter.