What is a migration plan
The Migration Plan is the operational document that guides migration execution. It is generated automatically based on the application information and completed assessment, and can be enriched by AI with procedures specific to the application's tech stack.
Create a migration plan
- Access the application or approved assessmentThe "Create Migration Plan" button appears on the assessment page after approval, or in the Migration Plans tab of the application.
- Set plan parametersConfirm the migration strategy, target OKD namespace, destination cluster and estimated cutover date.
- Generate the planClick "Generate Plan". The system calls the
MigrationProcedureGeneratorwhich builds all procedures, steps and checklists. - Review and approveA user with
migration-plans.approveapproves the plan for execution.
Generated plan structure
Procedures (Markdown)
| Procedure | Content |
|---|---|
| Migration Procedure | General migration runbook — phases, commands, verifications |
| Containerization Procedure | Containerization guide with Dockerfile example and OKD/K8s manifests |
| Cutover Procedure | Step-by-step cutover day guide (maintenance window, DNS switch, validation) |
| Rollback Procedure | Rollback plan in case cutover fails |
| Validation Checklist | Post-migration validation checklist |
| Day-2 Operations | Day-2 operations guide on Kubernetes/OKD |
AI active
With OpenAI configured, the Migration Procedure and Containerization Procedure are generated specifically for the application's stack (language, database, web server), with real commands, Dockerfile examples and contextualized OKD manifests.
Migration phases (Steps)
| Phase | Responsible role | Typical activities |
|---|---|---|
| 1. Preparation | Platform Engineer / Architect | Requirements analysis, OKD environment setup, namespace creation |
| 2. Containerization | Developer | Dockerfile creation, image build and push, local tests |
| 3. Configuration | Platform Engineer / Developer | ConfigMap and Secret creation, environment variable adjustment |
| 4. Data Migration | DBA | Dump, restore, integrity validation on the target database |
| 5. Deployment | Platform Engineer | Manifest apply, route/ingress configuration, HPA |
| 6. Testing | Developer / QA | Smoke tests, load tests, functional validation |
| 7. Cutover | Platform Engineer / Operations | Traffic switch, DNS update, monitoring |
| 8. Post-Migration | Operations | 72h monitoring, legacy environment decommission |
Executing the plan
With the plan approved, the team can execute steps directly on the platform:
- Each step can be marked as Pending → In Progress → Done
- Blocking steps halt progress if not completed
- Rollback Trigger steps automatically activate the rollback plan if they fail
- Checklists are marked individually in the interface
Key fields
| Field | Description |
|---|---|
migration_strategy | Strategy: rehost, replatform, refactor, re-architect |
target_platform | Target platform (okd, kubernetes, openshift) |
target_namespace | Namespace in destination cluster |
target_cluster | Destination cluster name |
estimated_cutover_date | Estimated cutover date |
estimated_effort_days | Total estimated effort in person-days |
estimated_duration_weeks | Estimated duration in weeks |
status | draft → approved → in-progress → completed |
Warning
Regenerating the plan replaces existing procedures. Steps and checklists already marked as completed will be reset. Export the plan before regenerating.