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.
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
- 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.
- You get a reminder. About 24 hours before the migration, Sevalla emails a reminder.
- Changes pause. When the migration starts, Sevalla pauses deployments and other changes for the whole company until it finishes. See During your migration.
- Each application switches. Sevalla stops the application on Google Cloud, starts it on OCI, checks that it answers, then points its domains at OCI. Applications linked by internal connections stop and switch together. An application can’t be reached for a short time between stopping and switching; the others keep serving from Google Cloud until their turn.
- Changes resume. Sevalla purges the caches, resumes changes and emails that the migration is complete, with your new locations and egress IP addresses.
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.
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 or your timing, for example a busy period to avoid or a service that needs extra care. 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.
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.
- 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.
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.
Frequently asked questions
Can I stay on Google Cloud?
Can I stay on Google Cloud?
No. OCI becomes the infrastructure under the whole platform, so every company moves. You can pick another time inside your wave’s window.
How do I know my migration is complete?
How do I know my migration is complete?
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.
What happens to databases and disks?
What happens to databases and disks?
They move in Wave 2, with applications that have a public TCP proxy. Wave 2 hasn’t started. Before it does, Sevalla emails each Wave 2 company its date and any extra steps, and the Migration notice lists them under Tasks.
Why was my migration postponed?
Why was my migration postponed?
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.