
Estimate cloud migration from the workloads, dependencies, data movement and operating changes involved. Separate one-time migration work, temporary parallel running and recurring cloud costs. A hosting quote alone does not price a migration, and moving servers does not by itself establish lower operating costs. This guide provides an estimation worksheet, not a Drema price list or an average market rate.

Let’s plan your cloud migration budget.
Bring your workflow, constraints and open questions. We’ll help you define the scope and work through the next decision.
Build the inventory around a business service
Start with a service people use, such as order processing, and trace what it requires: application processes, databases, files, scheduled jobs, identity, email, integrations and support access. An inventory of virtual machines can miss a nightly import that the business depends on.
For each component, record its owner, environment, usage pattern, capacity observations and recovery requirement. Mark unknowns explicitly. An estimate based on measured demand has a different confidence level from one based on a server's maximum allocation.
Use three separate budget sections
| Budget section | Items to include | What changes the estimate |
|---|---|---|
| Preparation and execution | Assessment, target setup, application changes, migration tooling, testing | Unsupported dependencies and incomplete documentation |
| Transition period | Parallel environments, replication, rehearsals, extra support coverage | Length of coexistence and acceptable interruption |
| Ongoing operation | Compute, storage, databases, logs, networking, backups, licences and support | Workload shape, retention, availability and traffic |
| Retirement | Export retention, account closure and dependency removal | Contract terms and unresolved consumers |
Keep billing assumptions visible: region, currency, pricing date, purchasing commitment, tax treatment and expected growth. Obtain current provider pricing for the selected services rather than transferring a figure from another project.
Work through an illustrative dependency
Suppose a hypothetical reporting application runs only during business hours, but its database must receive imports overnight. Turning everything off at night would break the next morning's report. A cost estimate needs separate schedules and dependencies for the application, database and import process.
Similarly, copying the initial dataset is only one data-movement task. Changes during rehearsal, final synchronisation, backups and access from another environment may create additional work or charges. Record the movement direction and anticipated volume without assuming every transfer is free.
Resolve the largest unknowns before quoting tightly
Use a short assessment to inspect connection paths, licence portability, runtime support, identity integration and restore capability. Give each unknown an owner and a way to close it. If the source database cannot be inspected yet, state that limitation alongside the estimate.
Compare options over the same period. A smaller initial bill can conceal more manual administration; a managed service can change staffing effort as well as infrastructure charges. Include the operating responsibilities in the comparison.
Questions about migration estimates
Can we estimate from the current hosting invoice?
Use it as an input, alongside actual utilisation, dependencies and recovery requirements. It does not describe all migration work or the target operating model.
When should contingency be added?
After identifying uncertainty. Tie a reserve to unresolved dependencies or migration tests rather than applying an unexplained percentage and calling the scope complete.
Prepare this inventory before discussing cloud and DevOps services. Then use the cloud migration checklist to turn the estimate into an executable transition plan.

