How to Decide the Future of Cloud Foundry Workloads?
A practical decision framework for evaluating Cloud Foundry workloads: stay, replatform, refactor, or retire.
Most Cloud Foundry conversations about “the future of the platform” start at the wrong altitude. They start with the platform, not the workload: “Should we stay on Cloud Foundry or move to Kubernetes?” as if every application in the estate needs the same answer.
It doesn’t.
A platform team under budget pressure, facing a contract renewal, or watching Cloud Foundry and BOSH skills become harder to hire, will feel real pressure to “do something.” That pressure is legitimate. But pressure to change is not the same as a case for change, and a technology trend is not a migration plan. Before any workload moves anywhere, it deserves its own answer, built on its own facts.
This article proposes a practical way to get there: stop asking what should happen to the platform, and start asking what should happen to each workload.
Migration Pressure Is Not Yet a Migration Case
Organizations typically cite a common mix of reasons for reconsidering their Cloud Foundry estate: rising license or contract costs, a renewal or vendor-change event, shrinking support for a given distribution, difficulty staffing experienced Cloud Foundry and BOSH operators, an infrastructure move (say, off vSphere or into a
different cloud), or a wider strategic push toward Kubernetes.
Each of these factors is a valid reason to review the application estate. However, none alone determines the best course for each particular application. Platform-level cost pressures do not imply every workload is costly, and a company-wide Kubernetes strategy does not mean every workload should migrate. Equating general pressure to change with the need to migrate all workloads is a common mistake in Cloud Foundry modernization efforts.
A common misconception in “Cloud Foundry to Kubernetes” discussions is the belief that migration is a straightforward, like-for-like process. In reality, Cloud Foundry provides many features that Kubernetes does not offer by default, such as the cf push developer experience, marketplace and service-broker model, tenancy and governance, identity, and routing conventions. Migrating to Kubernetes requires reassembling CI/CD, routing, identity, secrets, observability, policy, service consumption, backup and operational responsibilities. The key question is not “How do we move everything to Kubernetes?” but rather: “Which workloads should stay, which should modernize in place, which should move, and which actually require a rebuild.”
Evaluate Workloads, Not Platforms in the Abstract
At the workload level, six key questions guide the evaluation:
1. Business lifecycle. Is this workload still actively developed and strategically relevant, or is it stable, low-change, and low-priority?
2. Application fit. Does the workload still work the way Cloud Foundry expects? Stateless, deployable via buildpacks, reachable over HTTP routes, or has it grown requirements that no longer fit that model well?
3. Platform dependencies. How many of the platform features are in use by the workload and how deeply are they integrated? Common examples would be integration into the Cloud Foundry’s central monitoring and log forwarding system, service instances and the credential management via service bindings. What is the expected effort to migrate those?
4. Operational requirements. Does it have unusual needs around networking, scaling, specialized hardware, or deployment patterns that push against what its current platform offers?
5. Developer experience. What currently works well for the team that owns it, and how much of that would get harder or easier on a different platform?
6. Change cost and risk. What concrete benefit would a change deliver, and does that benefit clearly outweigh the effort and operational risk of getting there?
None of these questions has a universally right answer. That’s the point, they’re meant to produce different answers for different applications in the same estate, which is exactly what a mixed, multi-year Cloud Foundry and Kubernetes landscape looks like in practice.
Four Reasonable Outcomes
Applying those questions consistently tends to sort workloads into four buckets:
| Stay and modernize | The application still fits the Cloud Foundry model well, and a platform change wouldn’t create a clear, demonstrable benefit. |
| Replatform | The application can move largely unchanged, but its infrastructure or operating model should change to a different distribution method, to a different cloud or a different management model. |
| Refactor | The application needs capabilities or architecture that its current platform model doesn’t support well such as Kubernetes-native patterns, custom operators, specific networking, or GitOps-aligned delivery. |
| Retire or consolidate | The application has limited strategic value on its own, or its function can be absorbed by another service. |
A workload that lands in “stay” isn’t a workload the organization failed to modernize. A Cloud Foundry-native application that’s stable, well understood by its team and cheap to keep running has already met the bar. “Replatform” is often the underused option in this list: it lets an organization address the actual pressure driving the conversation, cost, contract, infrastructure, and staffing without forcing an application rewrite that it
doesn’t need. “Refactor” should be reserved for workloads where the current platform model is genuinely the constraint, not simply the default answer for anything that looks technically interesting. And “retire or consolidate” is worth stating explicitly because, in most estates, a nontrivial share of applications is still running mainly because nobody has revisited whether they should.
Coexistence Remains a Valid Target State
One implication of sorting by workload rather than by platform: a Cloud Foundry and Kubernetes estate that stays mixed for years isn’t a stalled migration. It can be the intended end state.
Treating coexistence as a temporary, embarrassing phase, something to be resolved as quickly as possible, tends to push organizations to move workloads before they’ve justified the move, which is exactly the failure mode this framework is meant to prevent. A deliberate split, where each workload sits on the platform that fits it, and the two platforms are connected and governed together, is often more economical and lower-risk than forcing convergence onto a single platform for its own sake.
Dependencies That Are Easy to Underestimate
The workload-level questions above surface most of what matters, but a handful of dependencies are consistently underestimated in planning, not because they’re obscure, but because they’re easy to treat as “someone else’s problem” until migration day:
● Identity and authorization. Users, identity providers, UAA clients, and org/space role assignments don’t follow the same migration pattern as applications and services. They need their own workstream: inventory identity providers, UAA clients, users, groups, and roles; provision the equivalent in the target environment; and verify SSO, redirects, and access rights before cutover, not after.
● Domains, routes, and certificates. Source and target environments typically run separate domains. Skipping deliberate domain and certificate planning is a common source of avoidable incidents, including the trap of an application landing on the wrong shared domain by default when no explicit route is specified.
● Service bindings and backing data. Every service comes with its own persistence model, expectations for state transfer between instances and consistency behaviour. If you need to switch for example from MySQL to MariaDB (or vice versa), which are almost fully compatible with each other you will need to validate against the list of known incompatibilities to ensure that the migration does not yield surprises.
Further, even when the same service is available and you simply “copy the data” this migration will almost certainly be the biggest and longest user-visible part of your workload migration, so factoring in the cost, effort and your customers/users tolerance for downtime is crucial.
● CI/CD and automation. Pipelines, deployment targets, credentials, and manifests are configured for a specific environment. They need to be verified and updated as part of the plan, not discovered broken after cutover.
● Concurrent operation. Not every application can safely run active-active across the source and target during a phased migration. Shared state, scheduled jobs, singleton processes, and message consumers all need to be checked before two versions of an application run in parallel.
These are not unusual challenges. They are standard inventory tasks that a workload-by-workload approach identifies early, rather than encountering them during migration.
For a step-by-step walkthrough of these workstreams, see anynines’ Cloud Foundry Migration Guide.
A Practical Pre-Migration Checklist
For platform teams adopting this framework to their own estate, a short starting
checklist:
● List every workload with an owner, business criticality, and current platform fit.
● Score each workload against the six evaluation questions above.
● Assign each workload a provisional outcome: stay, replatform, refactor, or retire.
● Separately inventory identity providers, UAA clients, users, groups, and role allocations.
● Separately inventory domains, routes, and certificate ownership.
● For each backing service in use, identify its supported data-transfer method and realistic downtime tolerance.
● Mark any workload with shared state, scheduled jobs, or singleton processes before planning parallel operation.
● Confirm CI/CD pipelines, credentials, and manifests are validated for the target environment before cutover.
● Keep a tested rollback path for each rollout, not just the first one.
● Revisit “stay” and “retire” decisions periodically; they’re not permanent, just currently correct.
The Bottom Line
Migration pressure is real and requires a considered response. The solution is not a single-platform decision for the entire estate, but a workload-by-workload evaluation based on consistent criteria. Some applications will stay, some will replatform, a few will require refactoring, and others should be retired. A resulting estate that includes both Cloud Foundry and Kubernetes, connected and intentionally managed, reflects a mature platform strategy rather than an incomplete migration.
The author of this post is Sven Schmidt, Senior DevOps with the Enterprise Platform Team of anynines. It is published as a sponsored post for Cloud Foundry Summit 2026.
