What actually determines the cost of a database migration
There is no market rate for "a database migration". What sets the price is not data volume but the number of things that must be verified.
This page is for teams that need to budget for a database migration but cannot see what an estimate rests on. GIIP does not present figures or savings percentages it has not established. Instead, here are the factors that drive cost, in the order they are decided.
No reference point for a budget
Published ranges are so wide that you cannot tell where your own environment sits.
Quotes are not comparable
Each vendor draws the scope line differently, so the same number covers different work.
Run-cost is invisible
You are given a project number, with no clarity on who operates it afterwards or for how much.
The same data volume can mean very different work
Table count, volume of stored logic and number of integrations can swing verification effort several times over. Data volume is not the main driver.
Downtime tolerance selects the method
The shorter the allowed outage, the fewer methods qualify — and the more preparation and rehearsal are required.
Verification scope is left vague
If nobody has agreed what "migrated" means in terms of checks passed, the estimates were never built on the same premises.
Before a number, establish what the number depends on. Estimates built on unstated premises cannot be compared.
Establish scale
Check both data volume and table count, and identify which of the two is the real difficulty.
Establish the verification scope
Enumerate dependencies, batches and external interfaces, and agree what will be checked before quoting.
Establish operational ownership
Decide whether GIIP operates afterwards or hands over, and present migration cost and run cost separately.
Factors that drive the cost
- Data volume (though not the main driver)
- Total number of tables and objects
- Volume of business logic in stored procedures and triggers
- Number of integrations with external systems
- Tolerable downtime
- Whether source and target are the same product or different ones
- How far verification is agreed to go
- Whether post-migration monitoring and operations are included
Scale we can evidence
These indicate the scale we can handle. Prices, effort and savings percentages differ per engagement, and figures that have not been established are not published here.
Frequently asked questions
Can you give a rough number up front?
A number produced before the premises are established is useless for both comparison and budgeting. We quote after checking scale, dependencies, downtime tolerance and verification scope, with the assumptions written down.
Will moving to cloud reduce costs?
We do not assert that it will. It depends on licensing terms, instance configuration and the operating model. We do not present savings percentages we have not established.
Is a small database cheaper to migrate?
Not necessarily. A small dataset with many tables and a lot of stored logic still means a lot of verification.
Is the run cost separate?
We present it separately. Bundling migration and operations hides the total you are actually committing to.
Large-scale database migration checklist — what to settle before you start
Check for free whether your database can be migrated SQL Server to AWSHow to migrate SQL Server to AWS, and what to check first
Check for free whether your database can be migrated Oracle to AWSHow to migrate Oracle to AWS, and how to choose the target
Check for free whether your database can be migratedEstablish the premises for an estimate on your terms
Tell us your scale, dependencies and downtime tolerance, and we will set out what is driving the cost.