Skip to main content
Sevalla is moving the applications and databases it runs on Google Cloud to Oracle Cloud Infrastructure (OCI). Sevalla migrates each company for you, with all of its services at once, in waves. Your domains, DNS records, connection URLs and deployment workflow stay the same. What changes is the location your services run in and the IP address their outbound traffic comes from. Applications connected to a database, or with a disk, are offline while they move, usually for a few minutes.

​
Migration status

A company moves in one wave, with every service it runs. Its wave follows from what it runs: if a Wave 1 company adds a database, a disk or a public TCP proxy, it moves to Wave 2 and loses its Wave 1 date. Sevalla kept some Wave 1 companies on Google Cloud on purpose. They move in November 2026 too, alongside Wave 2, the same way as the rest of Wave 1. The Migration notice in the top bar shows your wave. Static sites, object storage buckets and load balancers aren’t migrated. Static site builds have run on OCI, in Ashburn, since Wave 0, and sites are served from Cloudflare’s edge, so nothing else changes for them. New companies are created on OCI and have nothing to migrate. On Oct 15, 2026, Sevalla disabled the legacy hostnames and ports of TCP proxies and database external connections for every company, whatever its wave. See Legacy TCP proxy and external connection endpoints.

​
What changes for your services

​
How a migration runs

  1. You get a date. Sevalla emails your company owners, admins and developers the date and time (in UTC) of the migration, the locations your services move to and their new egress IP addresses. The Migration notice in the dashboard shows the same.
  2. You get a reminder. About 24 hours before the migration, Sevalla emails a reminder.
  3. Changes pause. When the migration starts, Sevalla pauses deployments and other changes for the whole company until it finishes. See During your migration.
  4. Each application switches. Sevalla stops the application on Google Cloud, moves the databases it’s connected to and its disk (if it has any), starts it on OCI, checks that it answers, then points its domains at OCI. Applications linked by internal connections stop and switch together; the others keep serving from Google Cloud until their turn. An application without a database or a disk can’t be reached for a short time between stopping and switching. An application with a database or a disk is offline for longer: see Applications with a database or a disk.
  5. Changes resume. Sevalla purges the caches, resumes changes and emails that the migration is complete, with your new locations and egress IP addresses.
If a check fails, Sevalla moves the services back to Google Cloud, resumes changes and emails that the migration is postponed. You get a new date by email.

​
Applications with a database or a disk

An application connected to a database, or with a disk, has planned downtime during its migration: Sevalla stops the application, moves every database it’s connected to (and its disk, if it has one), then starts everything again on OCI. Expect a few minutes for most applications, and longer for large databases or databases that are written to heavily.

​
Downtime

  • The application and its databases go offline together. Visitors get errors from when the application stops until it runs on OCI.
  • The length depends on your data. The downtime grows with how much changed in a database since its last backup. An application comes back only once its slowest database has moved.
  • Some visitors see errors a little longer. For a minute or two after the switch, some visitors may still get errors, depending on their location.
  • Running work is cut off. When the downtime starts, every process gets 30 s and is then stopped. Background jobs and long requests running at that moment don’t finish. Make sure your jobs can safely run again, or tell the migration team a time when none run in a note.
  • Changes pause for the whole company until the migration finishes. See During your migration.

​
What moves with a database

​
Databases on OCI

A migrated database runs as it is, on the same engine and version as on Google Cloud. That is Sevalla’s legacy database engine: it isn’t the same type of database you create in an OCI location once your company is on OCI.

​
Check your migration in the dashboard

The Migration notice in the top bar shows your wave until you have a date (Migration · Wave 1), then the date (Migration · Nov 3), then Migration in progress while it runs. When your migration completes, the notice disappears. Click the notice to open Migration to Oracle Cloud Infrastructure. It shows:
  • The three waves, with yours marked Your wave.
  • Schedule: the date and time in your time zone, with the time in UTC, or the status of your migration.
  • Tasks: what to do before your migration. The first task lists each Google Cloud location your company uses, its new OCI location and the new egress IP address.
  • Notes for our team: messages between your team and the Sevalla migration team.

​
Pick another time

Company owners, admins and developers can move the migration, once Sevalla has emailed your company its date.
1

Open the Migration notice

In the top bar, click the Migration notice.
2

Open the free times

Under Schedule, click Pick another time (or Pick a time if your migration has no date yet).
3

Choose a time

Click a free time. Times are in your time zone, at least 48 hours from now and inside your wave’s window. Optionally, add a Note for our team.
4

Move the migration

Click Move migration.
The dashboard confirms with Your migration moved to and the new date, and Sevalla emails the new date to your company. If the dialog says There are no other free times right now, leave a note for the migration team and they find a time with you.

​
Leave a note for the migration team

Notes tell the Sevalla migration team about your setup, your timing or any special request, for example a busy period to avoid, a database that is large or written to heavily, or a time when no background jobs run. Your team and the migration team can read them. A company keeps up to 50 notes of up to 2,000 characters each, and each user can delete only their own. Notes keep working while the migration runs.
1

Open the Migration notice

In the top bar, click the Migration notice.
2

Write the note

Under Notes for our team, type your note.
3

Add the note

Click Add note.

​
Before your migration

​
Allowlist your new egress IP address

After the migration, all outbound traffic from an application comes from the single fixed IP address of its OCI location. If an external database, payment provider, mail provider, API or firewall only accepts connections from known IP addresses, add the new address to its allowlist before your migration.
1

Find your new address

Open the Migration notice. Under Tasks, expand Prepare your third-party services for the new egress IP addresses and copy the New app egress IP of each location. The scheduling email lists the same addresses. You can also find your new location in New locations and look up its address in Egress IP addresses.
2

Add it to every allowlist

Add the new address next to the Google Cloud ranges you allow today. Keep the Google Cloud ranges until your migration is complete.
3

Remove the old ranges

After the completion email, remove the Google Cloud ranges from your allowlists.
An external service that only allows Google Cloud’s ranges stops accepting connections from your applications as soon as they run on OCI.

​
Plan around the migration

  • Don’t plan a release for the time of your migration: deployments are paused until it finishes.
  • Make sure clients of long-lived connections, such as WebSockets, reconnect on their own. Open connections drop when an application stops on Google Cloud.
  • If your application connects to a database or has a disk, plan for its downtime, and make sure background jobs can safely run again if they’re cut off.
  • Tell the migration team about anything that needs care, in a note.

​
During your migration

While your migration runs, the dashboard shows a Changes paused notice in the top bar: Your migration is in progress. You can still view everything in the dashboard. A deployment that was already running when the migration started finishes before any application switches.

​
After your migration

  • Deploy every commit you pushed during the migration.
  • Remove the Google Cloud ranges from your allowlists.
  • Delete preview apps of pull requests that closed during the migration.
  • Check each application’s location and its Egress IP addresses on its Networking tab. See Networking.
If something doesn’t work as expected, contact support.

​
New locations

Every Google Cloud location has an OCI location that replaces it. A Yes under City changes means the service moves to another city. A company with services in more than one Google Cloud location moves to the OCI location that replaces each one. For every OCI location and its egress IP address, see Locations and Egress IP addresses.

​
Legacy TCP proxy and external connection endpoints

On Oct 15, 2026, Sevalla disabled the legacy hostname and port of every TCP proxy and database external connection, for all companies, migrated or not. Since then, each TCP proxy and external connection works only on its new hostname and port. Clients that still use the legacy ones can’t connect. The deadline didn’t depend on your migration date, and the TCP proxies and external connections themselves stayed enabled. To fix a client that stopped connecting on Oct 15, 2026:
  • TCP proxy: open the application’s Networking tab and copy the hostname and port of the TCP proxy. The alert Your TCP proxy endpoint has changed lists the legacy endpoints under Show legacy endpoints, so you can tell which client used which. See Networking.
  • Database external connection: open the database’s Networking tab and copy the external connection’s hostname and port. If no new hostname shows, enable the external connection there to get one. See Connect to a database.
Internal connections between your services were never affected.

​
Frequently asked questions

No. OCI becomes the infrastructure under the whole platform, so every company moves. You can pick another time inside your wave’s window.
In November 2026. Sevalla schedules every remaining company, in Wave 2 or held back from Wave 1, and emails each one its date and time in UTC. You can pick another time at least 48 hours ahead.
Sevalla emails your company that the migration is complete, with your new locations and egress IP addresses. The Migration notice disappears from the top bar, your services show their OCI location, and each application’s Egress IP addresses show a single address.
They move in Wave 2, in November 2026, with the applications connected to them. The application and its databases go offline together while they move, usually for a few minutes. Data, connection URLs, passwords and backups stay the same. See Applications with a database or a disk.
No. Internal hostnames, connection URLs, database passwords and environment variables stay the same after the migration.
The email says why: your company now runs a database, a disk or a public TCP proxy and moved to Wave 2, the migration plan changed, the migration couldn’t start at the planned time, a check failed during the migration, or the migration team postponed it. Sevalla emails the new date when there is one.