We do not hand the database back at cutover — we keep running it
The hard part of a database migration is not copying the data. Unless compatibility, dependencies, performance, cutover, monitoring and incident response are designed together, the problems surface after you are already in production. GIIP works with large SQL Server, Oracle, TiDB, Aurora MySQL and PostgreSQL environments, and the same team continues operating them after the move to cloud.
We never ask for passwords, connection strings or data samples.
Nobody will tell you plainly whether it can be migrated
Database migration conversations usually stall not on technology, but on the absence of the facts needed to decide.
Too large to estimate
The more tables and instances there are, the more the verification work itself expands. Without agreement on how much checking is enough, nobody signs off on starting.
Compatibility problems arrive late
"MySQL-compatible" and "the same SQL Server" still carry different assumptions about execution plans, data types and locking. The heavy query appears after go-live.
No rollback design
If there is no procedure for the cutover going badly, the cutover cannot be approved in the first place.
No owner after the migration
The moment the project ends, an operational vacuum opens: nobody is watching, and performance regressions go unnoticed.
Fix the assumptions first, then carry through to running it
GIIP does not split development, infrastructure, database and operations across separate contracts. This is not a hand-off model.
Establish current configuration and scale
Product, version, instance configuration, data volume and approximate table count — so the real difficulty is identified before work starts.
Mechanical dependency inventory
Jobs, batches, external interfaces, stored procedures and triggers enumerated so completeness is demonstrated by reconciliation, not by eyeballing.
Cutover and rollback design
Tolerable downtime fixed as a business constraint, a method that fits inside it, and an explicit trigger and procedure for going back.
Continuous operations afterwards
The migrated cloud databases stay under continuous monitoring by AI agents and human experts. Operations do not stop when the project does.
Databases GIIP works with
The table below is the range GIIP has actually migrated or operated. For configurations not listed, we answer after reviewing your current environment.
| Source or operating environment | Migration / operations experience |
|---|---|
| On-premises SQL Server | Migration to AWS RDS for SQL Server |
| On-premises Oracle | Migration to AWS |
| TiDB | Migration to Amazon Aurora MySQL |
| Amazon Aurora MySQL | Monitoring, performance analysis, operations |
| AWS RDS for SQL Server | Monitoring, performance analysis, operations |
| Azure SQL Server | Monitoring and operations |
| Azure PostgreSQL | Monitoring and operations |
This table states the range of GIIP’s hands-on experience. It does not mean products outside the table cannot be handled — only that we do not claim experience we cannot evidence.
The scale we have actually handled
12 sets
of x12large-class, 5-replica AWS RDS for SQL Server deployed
~120,000
tables in an on-premises Oracle environment migrated to AWS
~3 TB
TiDB environment migrated to Amazon Aurora MySQL
~30
web services monitored continuously by AI, alongside multiple cloud databases
Large-scale migration track record
Customer names and business data are withheld under confidentiality. Only scale and scope are stated.
On-premises SQL Server → AWS RDS for SQL Server
Migrated to x12large-class, 5-replica environments, with 12 sets of that configuration deployed.
Oracle with ~120,000 tables → AWS
Handled dependencies, migration procedure and verification for an extreme object count.
~3 TB TiDB → Amazon Aurora MySQL
Migrated while verifying the differences between a distributed database and a MySQL-compatible cloud database.
From on-premises to AWS and Azure
Moving from on-premises to cloud changes operating assumptions even when the product name stays the same. Managed services give you no OS layer, so resident agents, local file integrations and OS-scheduler-dependent processing must be triaged first.
GIIP has migrated on-premises SQL Server to AWS RDS and on-premises Oracle to AWS. Because we operate databases on both AWS and Azure, we design without carrying one cloud’s assumptions into the other.
Schema, compatibility and query verification
The question is not "does it run" but "does it produce the same result".
- Identify differences in schema definitions — primary keys, indexes, constraints, partitions.
- Confirm that data type, character set and collation differences do not change the values themselves.
- Existing SQL will not necessarily produce the same execution plan on the target. Identify the queries that will get heavier, in advance.
- Enumerate stored procedures, triggers, jobs and batch dependencies so nothing drops out of scope.
- Make before/after reconciliation of counts and definitions something a machine runs, not a person.
Cutover and rollback planning
What usually decides whether a migration is viable is not the happy path but the design for the unhappy one. A cutover you cannot reverse is a business risk, not just a technical one.
- Fix in advance which node and which point in time is the reference at cutover.
- Agree the tolerable downtime with the business, then pick a method that fits inside it.
- Write down the rollback trigger — what has to happen for you to go back — and the steps it takes.
- Decide what is checked after cutover, and who checks it.
Downtime expectations differ by environment. We do not quote generic figures that are not backed by measurement.
Performance monitoring after migration
The period right after cutover is when queries that were never a problem surface, because execution plans, connection counts and batch load characteristics all change at once.
GIIP does not stop at cutover: the same team continues monitoring, performance analysis and operations. Cloud databases on both AWS and Azure are under continuous monitoring today.
On AWS DMS and other tooling
GIIP does not presuppose a particular migration tool. A managed tool such as AWS Database Migration Service fits some situations; a logical dump or replication is more reliable in others.
The tool follows from the source/target combination, data volume, tolerable downtime and the time available for verification. This page does not disclose which tools were used in specific engagements.
Pre-migration assessment
We do not take custody of confidential information at the consultation stage. These are the first things we check.
- 1
Current configuration
Database product, version, on-premises or cloud, and instance configuration.
- 2
Scale
Data volume and approximate table count — this determines which of the two is the real difficulty.
- 3
Dependency inventory
Jobs, batches, external interfaces and integrations with other systems.
- 4
Tolerable downtime
Whether zero downtime is required, or how many hours the business can absorb.
- 5
Method and verification plan
Options, verification items and rollback policy, presented with the assumptions stated explicitly.
- 6
Post-migration ownership
Whether GIIP continues to monitor and operate, or hands over.
Frequently asked questions
Which databases do you support?
The range GIIP has actually migrated or operated: on-premises SQL Server (migrated to AWS RDS for SQL Server), on-premises Oracle (migrated to AWS), TiDB (migrated to Amazon Aurora MySQL), and Aurora MySQL, AWS RDS for SQL Server, Azure SQL Server and Azure PostgreSQL for monitoring and operations.
How long does it take, and what does it cost?
It depends on data volume, table count, breadth of dependencies, tolerable downtime and the time available for verification. We do not quote generic figures that are not backed by measurement. Share your configuration and we will estimate with assumptions stated.
Do you use tools like AWS DMS?
We do not presuppose a tool. The method follows from the source/target combination, data volume and downtime tolerance. Sometimes a managed tool fits; sometimes a logical dump or replication is more reliable.
Can it be migrated with zero downtime?
Downtime requirements drive the choice of method. Whether zero downtime is a workable premise depends on data volume, write rate and how the application switches over, so we do not claim it is possible before checking.
Can you also monitor and operate it afterwards?
Yes. GIIP currently monitors and operates multiple Amazon Aurora MySQL, AWS RDS for SQL Server, Azure SQL Server and Azure PostgreSQL instances, plus approximately 30 web services, with AI agents and human experts.
What do we need to provide at the consultation stage?
Configuration information only: product, version, structure, approximate scale and downtime tolerance. We do not accept passwords, connection strings, personal data or data samples.
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
Related database migration & operations pages
Ask whether your database can be migrated and operated
Tell us your current configuration and the problem you are hitting, and we will lay out the decisions and the verification that matter.