Docs
Get Started

Migration

Kuberns migrations are source-driven. You connect the repository, the AI agent works out how the application builds and runs, and Kuberns provisions the resources it needs.

What Kuberns does not do is reach into your current provider. Databases, files, DNS records, secrets, and provider-specific services do not travel on their own. Those are the parts of the migration you plan for, and they are the same parts regardless of where you are coming from.

The shape of every migration

Whichever guide you follow, the sequence is the same. Deploy alongside your current setup, prove it works, and only then move traffic.

  1. Inventory the source, processes, variables, data stores, files, domains, and scheduled work.
  2. Deploy a non-production environment on the Kuberns URL. Nothing about this affects your live application.
  3. Provision resources and recreate environment variables with the new connection values.
  4. Import data and move persistent files.
  5. Validate logs, metrics, background jobs, scheduled work, and integrations.
  6. Lower the DNS TTL a day ahead of the cutover.
  7. Run the final data sync while the old application is not accepting writes.
  8. Point DNS at Kuberns and watch it.
  9. Keep the old service until the rollback risk is acceptable.

Three things that catch most teams

These come up in nearly every migration, so they are worth knowing before you pick a guide.

Scheduled work. Cron jobs, scheduled tasks, and platform schedulers are configuration on your current provider, not code in your repository. They do not migrate, and nothing reports an error when a job silently stops running. Find them during the inventory.

Data on disk. If your application writes files to local disk and expects them to survive, that needs external object storage. The Kuberns documentation does not describe a persistent-disk or volume resource, so plan for it rather than assuming it.

Loading your data is your step. Kuberns provisions an empty database and gives you the credentials. It does not restore a dump into a running datastore for you, in either direction. Practise the restore once before you depend on it.

Choose your guide

Each guide maps your current provider's concepts onto Kuberns and walks the same sequence with provider-specific detail.

Migrate from HerokuMap a Heroku application onto Kuberns: process types, config vars, add-ons, data, and domains.Migrate from RenderMove Render web services, workers, cron jobs, disks, data stores, and domains to Kuberns.Migrate from RailwayMove Railway services, reference variables, volumes, databases, and domains to a Kuberns project.Migrate from VercelDecide which parts of a Vercel project belong on Kuberns, then move them as a long-running container.Migrate from DigitalOceanMove an App Platform application or a hand-configured Droplet to Kuberns.Migrate from AWSMove an application you run directly on AWS onto Kuberns, and decide what stays on AWS.