Cloud Foundry to Cloud Run migration overview

The Cloud Foundry to Cloud Run migration guides provide background information on the differences between Cloud Foundry services and Cloud Run services, and show what you need to do to migrate Cloud Foundry applications to run in a container on Cloud Run. These migration pages do not cover data migration.

Cloud Foundry applications eligible for migration

Cloud Run is designed to run stateless HTTP or HTTP/2 applications. Your Cloud Foundry application cannot be migrated unless it meets the following criteria:

• Uses HTTP or HTTP/2 (including gRPC).
• Listens for traffic based on the PORT environment variable.
• Doesn't require routing on different paths to different applications.
• Doesn't require legacy Cloud Foundry "route services" for proxying traffic.
• Doesn't require an instance ID or a particular startup order.
• Doesn't need individual instances to be addressable.
• Can be started without side-effects to the environment, for example, starting a database migration.

Understanding the differences between Cloud Foundry and Cloud Run

Although Cloud Foundry and Cloud Run both share a similar source deployment experience, there are crucial differences in how the platforms approach workload containerization, application configuration and service definitions. Cloud Foundry and Cloud Run differences are shown in the following table:

How to migrate

To migrate a Cloud Foundry application:

1. Choose a strategy for building OCI-compliant containers
2. Migrate to OCI-compliant containers
3. Convert the manifest
4. Attach backing services
5. Deploy the service to Cloud Run

Sample migration

The Spring Music example uses core components of Cloud Foundry to rebuild Spring Music as an OCI compatible image and deploy it to Cloud Run. This sample follows the lift and shift OCI compliancy strategy.

What's Next

Choose your containerization strategy