A cloud sizing calculator can produce an instance recommendation without proving that the target architecture will meet the business workload. The input may cover CPU and memory but omit storage latency, log pressure, temporary space, replication, backups, connection behavior, licensing, failover, seasonal peaks, growth, or the cost of operating two environments during migration. The result is a hypothesis, not a production commitment.
Rightsizing also is not the same as selecting the smallest target that survived a quiet observation window. AWS Compute Optimizer, Azure migration assessment, and Google Cloud recommenders all use bounded telemetry and documented assumptions. Their output can improve a shortlist, but the accountable decision must explain the observation period, percentile, headroom, target constraints, missing evidence, performance test, total cost model, and rollback path. Complete the target validation before using that footprint in a database reserved capacity and commitment decision.
Does the migration business case depend on a spreadsheet estimate or a single vendor recommendation? Datrick can profile one production service, compare target scenarios, and validate the leading architecture with representative workload before cutover.
Define the sizing evidence contract
| Evidence layer | Capture | Decision question |
|---|---|---|
| Service identity | Business service, owners, environments, source engine and edition, topology, target candidates, region, deadlines, support status, RPO, RTO, and availability requirement. | What service outcome and risk boundary are being sized? |
| Workload window | Observation dates, business cycles, peaks, batch windows, month or quarter end, incidents, maintenance, seasonality, growth, and missing telemetry. | Does the sample represent the workload the target must survive? |
| Compute and memory | CPU distributions, runnable work, memory pressure, cache behavior, swaps, waits, concurrency, connections, query classes, parallelism, and headroom. | Which resources constrain throughput and tail latency? |
| Storage and log | Allocated and used capacity, growth, IOPS, throughput, read and write mix, latency, queue depth, temporary space, transaction log or WAL, checkpoints, and burst behavior. | Can the target sustain data and log demand without hidden throttling? |
| Topology and operations | HA, replicas, DR, backups, retention, restore, CDC, ETL, BI, maintenance, monitoring, security, encryption, networking, proxies, and failover. | What additional capacity and cost does the production architecture require? |
| Commercial inputs | Compute, storage, provisioned performance, licenses, backup, transfer, support, monitoring, migration tooling, temporary overlap, labor, commitments, and currency assumptions. | What is recurring run rate, one-time cost, and uncertainty? |
| Target constraints | Service tiers, engine versions, instance families, storage limits, IOPS and throughput relationships, maintenance, scaling, replica limits, regional availability, and quotas. | Which candidate architectures are technically valid? |
| Validation outcome | Dataset, configuration, workload replay, concurrency, transactions, latency distributions, throughput, resource saturation, errors, failover, cost projection, and residual risk. | Which target is supported by evidence rather than mapping? |
Separate capacity, utilization, and service requirement
Installed source capacity describes what exists. Utilization describes what happened during a particular window. The service requirement describes what must be delivered under expected demand and failure conditions. Treating these as interchangeable causes predictable errors: lifting an oversized server preserves waste, while sizing only to observed averages removes safety margin and ignores workload growth.
Normalize telemetry into comparable units and distributions. Capture peaks and sustained demand, not only daily averages. Relate database metrics to business workload: orders, users, files, jobs, reports, API calls, or model runs. Mark periods distorted by incidents, maintenance, throttling, or missing collection. If memory, storage latency, transaction log, query, or application telemetry is absent, state the uncertainty instead of replacing it with a confident estimate.
Use vendor recommendations as inputs, not approval
AWS Compute Optimizer can classify RDS resources as under-provisioned, over-provisioned, or optimized using CloudWatch history and can compare projected utilization. For RDS, the configurable recommendation preference is primarily the lookback period. CloudWatch Database Insights adds database load and fleet performance evidence. Together they are useful after workloads run on AWS, but they do not independently prove a proposed migration target, application behavior, recovery design, or complete cost model.
Azure migration assessments support performance-based sizing, configurable percentiles, scaling factors, observation ranges, and multiple SQL targets. Google Cloud's Cloud SQL recommender evaluates CPU and memory for eligible primary instances over a defined history and explicitly advises teams to review context before applying a smaller size. These documented limits reinforce the same control: retain the recommendation inputs and assumptions, then validate the resulting architecture.
Build a controlled sizing and validation workflow
| Component | Responsibility | Production control |
|---|---|---|
| Read-only collector | Collect inventory, topology, database, host, storage, query, application, backup, network, incident, cost, growth, and business-cycle evidence. | Least privilege, secret redaction, source timestamps, completeness checks, and no configuration changes. |
| Workload normalizer | Align time zones, intervals, units, percentiles, peaks, outliers, gaps, maintenance, and business events across sources. | Raw evidence remains immutable; every transformation is versioned and reproducible. |
| Target constraint catalog | Represent supported engines, service tiers, instance and storage limits, IOPS, throughput, HA, replicas, licensing, maintenance, and regional constraints. | Versioned official sources; stale or unsupported target data abstains from recommendation. |
| Scenario model | Generate baseline, conservative, growth, peak, failure, and alternative-architecture candidates with explicit headroom and assumptions. | No candidate is ranked when a hard requirement is unknown or violated. |
| Cost model | Separate recurring and one-time costs, quantify ranges, preserve price date and currency, and show which architecture element creates each cost. | Pricing inputs are refreshed before approval; commitments and discounts are not assumed. |
| Workload validator | Provision an isolated target, load representative data, replay important queries and transactions, test concurrency, failover, backup, monitoring, and operations. | Approved data handling, deterministic assertions, spending limits, teardown, and no production endpoint changes. |
| Decision dossier | Connect each recommendation to evidence, assumptions, test results, cost sensitivity, residual risk, owner, expiry, and next action. | Named DBA, application, platform, finance, security, and business owners approve the target. |
Model total cost instead of instance price
Build the cost model from the architecture. Include primary compute, high availability, read replicas, storage capacity, provisioned IOPS or throughput, backups and snapshot retention, cross-zone or cross-region traffic, application transfer, monitoring, support, encryption dependencies, licenses, migration services, temporary environments, dual running, validation, and ongoing operations. Track taxes and discounts separately where relevant.
Do not mix a one-time migration budget with the recurring production run rate. Show baseline, expected, and stress scenarios with dated inputs. Add growth and retention sensitivity. A small change in data volume, replica count, provisioned performance, backup policy, licensing, or transfer pattern can matter more than the chosen instance family. A defensible estimate exposes these drivers instead of hiding them inside one monthly number.
Validate performance on the intended architecture
Use a recent production-representative copy with realistic size, distribution, indexes, statistics, configuration, encryption, and important integrations. Replay a ranked workload containing latency-sensitive reads, writes, transactions, batch, reporting, maintenance, ETL, and concurrency. Include warm and cold cache behavior when relevant. Measure p50, p95, and p99 latency, throughput, errors, CPU, memory, IOPS, throughput, storage latency, queueing, log pressure, locks, connections, replication lag, and cost during the run.
Test the architecture, not an isolated database. Include application pools, drivers, proxies, DNS or endpoint behavior, network path, authentication, TLS, replicas, backups, monitoring, maintenance, failover, and restore. A database benchmark can pass while the end-to-end business transaction fails its latency objective because of network, pool, driver, or application behavior.
Rehearse peaks, failures, and growth
Run more than the median day. Model known seasonal peaks, month-end or quarter-end jobs, campaigns, customer onboarding, data backfills, maintenance, and expected growth. Add failure cases: one replica unavailable, failover in progress, storage burst exhausted, backup active, long transaction, increased network latency, or a competing batch workload. The target should meet agreed service thresholds under the scenarios the business has chosen to fund.
Headroom must be explicit. State whether it protects growth, failover, telemetry error, deployment variance, or unexpected demand. Excess headroom is cost; unexplained low headroom is risk. The decision dossier should let a buyer see how much each risk allowance costs and which evidence would justify changing it.
Plan post-cutover rightsizing without premature downsizing
The migration target is an initial production configuration, not a permanent entitlement. Define a post-cutover observation period with stable workload, complete monitoring, and no unresolved migration defects. Compare actual demand, performance, and cost with the model. Investigate differences before changing capacity; a low-utilization period may reflect missing traffic, disabled jobs, caching changes, or an incomplete migration.
Use cloud-native recommendations as one signal after the new workload has enough representative history. Require a change window, rollback, before-and-after evidence, and application SLO monitoring for every downsize. When several small targets remain, use a separate database consolidation and workload isolation assessment before placing them on shared capacity. Retain the reasoning so the next review understands whether capacity was preserved for a known peak, recovery event, contractual SLO, or growth forecast.
Keep AI inside a supervised boundary
- AI may: normalize metrics, detect missing evidence, cluster workload periods, map target constraints, generate comparable scenarios, explain cost drivers, compare test results, and draft a decision dossier.
- AI must not: invent telemetry, assume a discount, expose secrets or production data, provision uncontrolled resources, change database size, apply a recommendation, redirect applications, or approve migration readiness.
- Deterministic controls: unit conversion, target eligibility, capacity limits, price-date checks, workload assertions, performance thresholds, cost ceilings, test teardown, approvals, and post-change verification.
- Human accountability: technical and business owners choose the funded service level, headroom, residual risk, migration target, and production change.
Evaluate recommendation and migration outcomes
- Evidence quality: telemetry coverage, business-cycle representation, missing periods, unit accuracy, inventory completeness, source freshness, and workload-to-business mapping.
- Recommendation quality: valid-target rate, expert agreement, constraint violations, performance-risk recall, cost-estimate error, uncertainty calibration, and abstention quality.
- Validation quality: workload coverage, transaction correctness, latency distributions, throughput, saturation, failover, backup, monitoring, repeatability, and unexplained variance.
- Production outcome: cutover performance, incidents, SLO compliance, actual versus forecast cost, emergency scaling, overprovisioning, post-cutover rightsizing, and owner acceptance.
- Operational value: assessment cycle time, manual analysis reduced, evidence reuse across the fleet, avoided rework, and time from telemetry to approved decision.
Pilot one business service and target architecture
- Select one business-critical database migration with a defined source, target shortlist, deadline, availability requirement, and accountable owners.
- Collect at least one representative workload window covering relevant peaks, business cycles, storage behavior, queries, topology, recovery, incidents, growth, and current cost.
- Define target constraints, service requirements, uncertainty, headroom, and baseline, conservative, growth, and failure scenarios.
- Produce comparable architectures and total-cost ranges with dated pricing inputs, one-time migration cost, recurring run rate, and sensitivity drivers.
- Build the leading target in an isolated environment, load representative data, and run application, query, concurrency, operational, failover, and restore validation.
- Resolve gaps, repeat critical tests, and issue an evidence-backed recommendation with assumptions, residual risks, cutover controls, and post-cutover measurement plan.
- Expand to more databases only after forecast accuracy, test coverage, production performance, cost variance, and owner acceptance meet the pilot gate.
A focused assessment and target validation often take four to eight weeks. Weak telemetry, unrepresentative data, seasonal demand, licensing constraints, complex topology, multiple clouds, and strict recovery requirements usually extend the program.
Frequently asked questions
What is database cloud migration sizing assessment?
It is an evidence-based assessment that converts source inventory, representative workload telemetry, growth, availability, recovery, licensing, and operational requirements into comparable target architectures, cost scenarios, and workload validation results. It is broader than mapping the current server to a cloud SKU.
Can a cloud database sizing recommendation predict production performance?
No. A recommendation is a useful hypothesis based on the metrics, observation period, percentile, scaling factor, and service constraints it can see. Production performance still requires target-representative configuration, data, concurrency, queries, integrations, failover, and application transaction testing.
What costs should a cloud database migration assessment include?
Include database compute, high availability, read replicas, storage capacity, IOPS and throughput, backup retention, snapshots, monitoring, data transfer, support, licenses, migration tooling, temporary overlap, test environments, operations, and expected growth. Separate recurring run rate from one-time migration cost and uncertainty.
How do you validate database size before a cloud migration?
Capture representative source telemetry across peaks and business cycles, model multiple target scenarios, restore or replicate production-representative data, replay important workload at expected concurrency, measure latency and resource distributions, test operational requirements, and compare results with approved thresholds and cost assumptions.
How long does a database cloud migration sizing assessment take?
A focused assessment and target validation for one business service often take four to eight weeks when inventory, telemetry, workload evidence, cost inputs, a representative data copy, target access, and accountable owners are available. Seasonal workloads, large fleets, licensing complexity, weak observability, or multiple target platforms extend the program.
Official implementation references
- AWS Compute Optimizer Aurora and RDS recommendations
- Amazon CloudWatch Database Insights
- Amazon RDS storage
- Azure Migrate SQL assessment calculations
- Azure Data Migration SKU recommendation
- Google Cloud SQL overprovisioned instance recommendations
Start with the database whose cloud business case carries the largest performance or cost uncertainty. Datrick can profile the workload, compare target architectures, validate the leading scenario, and leave an auditable decision before a production commitment.