Fill gaps from assistant conversations: step-by-step Flightcontrol migration - #44
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
|
|
PR author is not in the allowed authors list. |
|
|
||
| Point the agent at [Start here (human + agent)](/start-here) and this page so it has the mapping table above and the [project config file workflow](/config-as-code/project-config-file#agent-tips). | ||
|
|
||
| Verify the draft against the mapping table before applying anything. `rvn-ecs-web` and `rvn-ecs-worker` both require an `rvn-ecs-cluster`, and `rvn-cloudfront` is now opt-in per service instead of always-on. |
| **Do not redeploy in Flightcontrol during migration.** New deploys go through Ravion from this point on. The Flightcontrol service keeps serving old traffic until DNS moves and you delete it. | ||
| </Step> | ||
|
|
||
| <Step title="Delete the migrated Flightcontrol services"> |
There was a problem hiding this comment.
we need a big warning here to not delete an imported service from FC, contact support to have us remove it from your account, we are working on self serve delete from FC without destroy
There was a problem hiding this comment.
Added a Warning in that step: never delete an imported service in Flightcontrol (it destroys the AWS resources Ravion now manages) — contact support to have it removed without destroy, self-serve coming.
There was a problem hiding this comment.
but remove the stop deploying anything, that not accurate
| <Step title="Cut traffic over one service at a time"> | ||
| Deploy the service in Ravion, verify it's healthy, then update DNS to point at the Ravion load balancer or CloudFront distribution. Leave the Flightcontrol service running until you've confirmed the cutover. | ||
|
|
||
| **Do not redeploy in Flightcontrol during migration.** New deploys go through Ravion from this point on. The Flightcontrol service keeps serving old traffic until DNS moves and you delete it. |
There was a problem hiding this comment.
change this to only be for things that are imported. other like ecs can continue to be deployed via FC, no problem.
There was a problem hiding this comment.
Scoped it to imported resources only; provisioned-new services (ECS, static sites) can keep deploying via Flightcontrol until DNS moves.
Co-Authored-By: brandon <brandon@flightcontrol.dev>
| Once each service is fully cut over, remove it from Flightcontrol so you're not paying for duplicate infrastructure. | ||
|
|
||
| <Warning> | ||
| **Never delete a service in Flightcontrol that you imported into Ravion.** Deleting it in Flightcontrol destroys the underlying AWS resources that Ravion now manages, including databases and buckets. |
There was a problem hiding this comment.
this not clear enough, needs to be more clear that this is for things you imported the infra into ravion (like rds) instead of creating a new module in ravion like ecs.
1 participant
Summary
Adds an explicit ordered migration procedure to the Flightcontrol migration page so readers can complete the migration without asking the assistant to synthesize the steps.
Changes
migrate/from-flightcontrol.mdx, placed between the service-type mapping table and "Migrating services".ravion.yamlfrom an existing Flightcontrol config, using the Docs MCP and the mapping table.Context
Recent assistant conversations showed users asking whether there's a one-click migration, whether they can use an AI agent to convert their Flightcontrol config, and whether they should keep deploying in Flightcontrol during migration. The mapping table and per-service notes were already on the page, but the ordered flow tying it all together was missing.