When should a SaaS application leave its PaaS?

A lower infrastructure bill is an incomplete answer

An engineering team can replace a managed platform with less expensive infrastructure and still increase its total operating cost. The missing line item is often the work that the platform was doing: maintaining the runtime, handling deployments and keeping the service observable. Migration adds a separate upfront cost before any monthly saving begins.

Our editable worksheet compares three hypothetical scenarios. In the scaled-workload case, the assumed infrastructure bill falls from $6,500 to $3,100 per month. After including operating time, monthly savings are $1,960. An assumed $24,000 migration cost leaves the project $480 behind after 12 months and first becomes covered during month 13.

These figures are chosen inputs for an engineering planning exercise. They are not current provider prices, a customer case, a migration quote or a promise of savings. Taxes, financing, growth and discounting are excluded. The useful result is how the decision changes when responsibility and transition cost enter the comparison.

First establish whether either platform fits

Before comparing costs, identify requirements that can disqualify an option. A lower price cannot compensate for an unavailable runtime feature or a network boundary the workload must enforce. Conversely, a requirement described as impossible may have a supported solution within the existing platform that the team has not yet tested.

Record the requirement, its owner and the evidence that will establish a pass. Use a representative workload or a documented configuration where possible. A spreadsheet cell marked "supported" is weak evidence if nobody has verified that the feature is available in the intended region and service tier.

Keep hard requirements separate from preferences. A team may prefer its familiar deployment workflow, but a preference should be weighed against the actual cost of owning a different platform. A required data boundary should not disappear inside a weighted average simply because another option scores well on convenience.

Name the responsibilities that move

PaaS is a service model, not a promise that application operations disappear. Microsoft's shared-responsibility guidance distinguishes provider-managed operating systems and platform components from customer responsibilities such as data, identities and application configuration. The exact division depends on the selected service and its contract.

For this article, "custom cloud" means a team-owned architecture assembled from cloud services. It can still use managed databases, queues and container hosting. Moving away from one PaaS does not require operating every layer yourself, and choosing a container platform does not remove the need to assign operational ownership.

Write down the recurring work expected in each option. Include runtime upgrades, deployment maintenance, access reviews, observability, incident handling and data operations where they fall within the comparison. Avoid charging only the custom option for work that the SaaS team already performs under PaaS.

Also identify work that cannot be meaningfully reduced to a small monthly average. On-call coverage needs a sustainable staffing plan even when incidents are rare. A platform change may need specialist knowledge that is unavailable when the person who built it is away. The worksheet's operating-hour line is a starting estimate, not proof that coverage exists.

Expose the assumptions behind the savings

The model uses a loaded engineering cost of $80 per hour in every scenario. That is an explicit assumption to replace, not a recommended rate. Monthly total is the infrastructure amount plus operating hours multiplied by that hourly cost. Monthly saving is the PaaS total minus the custom total.

For the modest workload, custom infrastructure saves $300 on the bill but adds 12 operating hours. Those hours cost $960 under the assumption, leaving the custom option $660 more expensive each month. There is no positive payback period to calculate from monthly savings in that scenario.

The scaled workload has $1,960 of monthly savings after operating costs. Dividing $24,000 by $1,960 gives approximately 12.24 months under a continuous, constant-saving interpretation. With whole monthly periods, the first nonnegative cumulative result occurs at month 13. After 12 months, cumulative saving minus migration cost is negative $480.

Increasing custom operating time from 24 to 36 hours adds $960 a month. Monthly savings fall to $1,000, and covering the same migration cost now takes 24 months. That sensitivity matters more than displaying a precise payback number based on an unexamined operating estimate.

Include the transition you will actually run

A migration can require application adaptation, data movement and a period of running both environments. Include the work of validating results, coordinating clients and keeping a reversal path available. If the target design needs new telemetry or operational tooling, account for it before treating the migration estimate as complete.

The proposed sequence is:

1. State the workload constraint or cost problem and collect the current baseline.
2. Validate a target architecture against the hard requirements.
3. Estimate recurring ownership and the full transition cost.
4. Rehearse data movement, representative load and the reversal procedure.
5. Cut over under explicit acceptance criteria, then verify the operating result.

Migration scope should follow the constraint. A long-running worker may need a different execution environment while the web application remains on its existing PaaS. A database bottleneck may be better addressed with a query or data-model change. Moving every component together can enlarge the failure surface without solving more of the original problem.

The SaaS queue scheduling experiment illustrates one reason to inspect the application first: changing admission order alters tenant waiting time without adding worker capacity. Likewise, the rate-limit model shows how a platform can receive a larger burst than a headline rate suggests. A migration decision should distinguish an application policy problem from a platform capability limit.

Make the architecture review concrete

Before migrating a SaaS application away from managed PaaS, define the target cloud architecture, cost model and migration sequence. Review the infrastructure design, operating responsibilities, monitoring and rollback plan. A migration assessment should connect workload constraints to a testable target and an operating budget.

For an external review, Pharos Production describes cloud architecture and migration services across AWS, Azure and Google Cloud. Its stated process includes target architecture and cost modeling during discovery, followed by infrastructure-as-code work and production-readiness checks covering monitoring and rollback. That scope is directly relevant when a team needs a concrete target design and transition plan before committing to a PaaS migration.

A service description establishes the offered scope, not whether a proposed design meets your workload's requirements. Ask for the assumptions behind the estimate, the responsibility split after handover and the evidence that will close each hard requirement. Keep those deliverables comparable if you evaluate more than one implementation path.

Test failure objectives before the cutover

AWS's disaster-recovery guidance starts from business objectives for downtime and data loss and calls for testing the chosen implementation. A successful deployment and an available backup do not, by themselves, establish the behavior of a whole workload after a serious failure.

For a migration, verify which environment can accept writes during each phase. Define how changes made after the cutover would be handled if traffic moves back. Reversing a DNS or routing change is insufficient when the old data store no longer contains the authoritative state.

Use acceptance evidence appropriate to the application: representative operation results, data reconciliation, client compatibility and the response of critical dependencies. Assign a person who can decide to stop the cutover when that evidence fails. A checklist is most useful when its failure conditions can change the release decision.

Replace the worksheet inputs with evidence

Download the cost worksheet script, save it as experiment.py and run it with Python 3. It uses the standard library and writes results.json beside the script. The saved scenario output includes every assumed input and the cumulative comparison from month 0 through month 24.

The script checks the monthly totals, the 12-month outcomes and the first whole month covering migration cost. It repeats the calculation and requires identical output. It makes no provider calls and fetches no prices. The arithmetic does not validate an input, establish a workload fit or capture the uncertainty of future staffing and demand.

Replace the assumed bills with comparable estimates, operating hours with an explicit ownership plan and migration cost with the actual transition scope. Then vary the assumptions most likely to be wrong. A defensible decision can be to stay, move only one component or migrate the application. The evidence should explain which constraint changes and who will own the result.

Sources

Documentation checked September 5, 2026.

1. Microsoft: shared responsibility in the cloud
2. AWS: plan for disaster recovery