One-Time Migration Cost vs Recurring Healthcare Operations

A healthcare migration has at least four budgets: one-time engineering, one-time program work, recurring cloud usage, and recurring operations. Combining them creates a misleading quote. A low monthly server estimate may hide a large schema rewrite, while a large migration estimate may be unrelated to the eventual provider bill.

Model the buckets separately, attach assumptions to every range, and state what remains unpriced. A migration is complete only when data, identity, regional controls, queues, backups, support, and evidence have been verified.

Cost surface and assumptions

Write down the current and target architecture before estimating hours. Count application services, scheduled jobs, databases, indexes, queues, secrets, regions, logs, backups, support paths, and integrations. The number of services is not a complete estimate, but it prevents the common mistake of pricing compute while ignoring persistence and recovery.

The Google Cloud Cloud Run Pricing page describes request and resource charges. The Google Cloud Cloud SQL Pricing page describes instance, storage, and availability costs. These pages are price references retrieved 2026-08-15. They do not estimate the engineering required to move an existing application.

AWS Lambda’s pricing page separates requests, duration, and free allocations. Use it for the target runtime line only. If the target changes a document database into a relational model, estimate schema and query work separately.

For a detailed hours model, read how to bound healthcare migration hours. For recurring reserve, read compliance reserve pricing.

One-time work versus recurring work

One-time work usually includes discovery, data-flow mapping, target design, infrastructure setup, identity configuration, migration code, reconciliation, cutover, rollback planning, negative tests, restore tests, and initial documentation. Add application changes when the target database or regional model changes query semantics.

Recurring work begins after launch. It includes access reviews, vendor review, policy updates, risk review, training, incident exercises, restore drills, support, queue operations, dependency upgrades, and future migration work. A recurring reserve should not be disguised as “maintenance included” when the operator has no hours allocated.

Bucket	Question	Evidence of completion
Compute migration	Can the application run with production-like identity and jobs?	Deployment and smoke tests
Data migration	Are schema, counts, indexes, and queries reconciled?	Signed reconciliation report
Control migration	Do keys, secrets, logs, backups, and roles follow policy?	Configuration and denial tests
Launch	Can the system roll back without losing accepted writes?	Cutover and rollback drill
Operations	Who maintains evidence and responds to failures?	Runbook, owner, and reserve

The Cloud SQL pricing page is useful for spotting an always-on database floor. That floor may stay stable while migration labor remains the dominant one-time cost. Do not infer that a low instance price means a low migration price.

Scenario table and uncertainty register

Use a planning table such as this, then replace ranges with measured hours and provider quotes.

Route	One-time focus	Recurring focus	Uncertainty
Runtime lift	Container, identity, jobs, domains	Logs, deploys, support	Database bridge and contract scope
Document database migration	Schema, queries, backfill, reconciliation	Indexes, backups, reports	Query completeness
Relational migration	Schema, constraints, authorization, cutover	Instance, HA, patches, restores	Availability requirement

Mark each number as observed, estimate, quote, or unresolved. State whether the range includes owner labor, testing, counsel, taxes, support, unusual egress, and downtime. If it does not, show those lines rather than silently absorbing them.

Migration approval gate

1. Freeze the current data-flow and access inventory.
2. Prove one vertical slice in the target environment before broad conversion.
3. Measure query, transaction, export, restore, and tenant-denial behavior.
4. Reconcile record counts and signed manifests before cutover.
5. Set rollback, old-store deletion, and support procedures.
6. Approve recurring operations and reserve funding separately.

Stop when the target database has not passed a real query and authorization proof, when the rollback path is untested, or when the quote treats compliance evidence as free. A deployment is not ready because the build succeeds.

Use backup restore testing and tenant isolation denial tests as explicit gates. Keep the scope of the migration claim aligned with the proof.

Frequently asked questions

Why is migration cost separate from cloud cost?

Cloud cost pays for resources and operations. Migration cost pays for engineers to change code, data models, access controls, jobs, tests, and cutover procedures. The two can have different owners, timing, and uncertainty.

Does a serverless target eliminate recurring cost?

No. Request-based compute may scale down, but storage, backups, logs, keys, DNS, support, evidence, and integrations remain. Recalculate the complete production stack instead of using only function pricing.

When should a migration stop?

Stop when a vertical slice fails authorization, query completeness, reconciliation, restore, or rollback proof. Fix the boundary before expanding migration scope. A smaller verified slice is more useful than a larger unverified cutover.

References

• Google Cloud, Cloud Run Pricing, retrieved 2026-08-15: https://cloud.google.com/run/pricing
• Google Cloud, Cloud SQL Pricing, retrieved 2026-08-15: https://cloud.google.com/sql/pricing
• Amazon Web Services, AWS Lambda Pricing, retrieved 2026-08-15: https://aws.amazon.com/lambda/pricing/