Assessing Readiness
Before diving into migration work, take time to evaluate your application's current state. This assessment helps you identify potential blockers, estimate effort, and choose the right migration approach.
What You'll Learn
- How to evaluate your application's platform compatibility
- Common migration blockers and how to address them
- What artifacts you'll need to gather
- How to prioritize what to migrate first
Application Assessment
Answer these questions about your application to understand the migration scope:
Current State
| Question | Considerations |
|---|---|
| Is it containerized? | If yes, you may only need to adjust the Dockerfile. If no, containerization is your first task. |
| Where does it run today? | VMs, bare metal, another container platform? This affects how much infrastructure knowledge transfers. |
| How is it deployed? | Manual, scripts, existing CI/CD? Existing automation can often be adapted. |
| What language/framework? | The platform has specific actions for JavaScript, Python, .NET, Java, and Rust. |
Dependencies
| Question | Considerations |
|---|---|
| What databases does it use? | Managed databases work well. Self-hosted databases need migration planning. |
| What external services? | APIs, message queues, caches? These need network connectivity in the cluster. |
| What internal services? | Other applications in your organization? These may need to migrate together or have stable endpoints. |
| What secrets/configuration? | Credentials, API keys, environment-specific config? These move to cloud secret stores. |
Runtime Requirements
| Question | Considerations |
|---|---|
| Does it need local filesystem? | Containers are ephemeral. Persistent storage needs explicit configuration. |
| Does it need specific hardware? | GPU, special CPU features? These require node affinity configuration. |
| Is it stateful? | Session affinity, in-memory state? These need architectural consideration. |
| What ports does it expose? | HTTP, gRPC, custom protocols? All are supported but configured differently. |
Platform Compatibility Checklist
Use this checklist to identify what work your application needs:
Required for Deployment
These items must be addressed before your application can run on the platform:
- Application can run in a container — No hard dependencies on host OS configuration
- Container image is accessible — Image published to Artifactory or another registry the platform can pull from
- Configurable via environment variables — No hardcoded environment-specific values
- Secrets can be injected — Application reads secrets from environment or mounted files
- Has a health check endpoint — At minimum, a path that returns 200 when ready
Recommended for Production
These items aren't strictly required but strongly recommended:
- Logs to stdout/stderr — Platform collects logs from standard streams
- Graceful shutdown — Handles SIGTERM to finish in-flight requests
- Stateless or externalized state — State stored in databases/caches, not local memory
- Reasonable startup time — Starts within a few minutes (startup probes can accommodate slow starts)
- Resource bounds known — You know typical CPU/memory usage for sizing
Nice to Have
These can be added incrementally after initial deployment:
- Structured logging — JSON-formatted logs with consistent fields
- Metrics endpoint — Prometheus-format metrics on
/metrics - Distributed tracing — OpenTelemetry instrumentation
- Comprehensive health checks — Detailed status including dependency health
Common Blockers
If your assessment identifies any of these issues, you'll need to address them before deployment:
| Blocker | Quick Summary |
|---|---|
| Configuration hardcoding | Move to environment variables |
| Filesystem dependencies | Use object storage or databases instead |
| Hardcoded service URLs | Use environment variables for service discovery |
| Long startup times | Configure startup probes with appropriate thresholds |
| In-memory session state | Externalize to Redis or use stateless tokens |
For detailed solutions to each blocker, see Deployments Troubleshooting.
Useful Information to Gather
Having this information handy will speed up your migration:
- Environment variables — What configuration does your application need?
- Secrets — What credentials are required (database passwords, API keys)?
- Ports — What ports does your application listen on?
- Resource usage — Typical CPU and memory consumption for sizing
Next Steps
Once you've assessed your application:
- Address any hard blockers identified in the compatibility checklist
- Gather the required artifacts
- Proceed to Builds to set up CI/CD and containerization
Related Documentation
- Builds — Setting up CI/CD pipelines
- Deployments — Creating PlatformApplication manifests
- Observability — Adding monitoring capabilities