If you already have a working n8n setup somewhere, the last thing you want during a migration is a downtime gap where webhooks fail and Slack notifications go to nobody. Good news: FlowEngine gives you three real ways to bring an existing setup onto a managed instance, each one fitting a different starting point.
The right path depends on what you have today.
Pick the path that fits
- Path A. Whole-instance import from a database dump (S3 URL or upload). Use this if you have a self-hosted n8n with shell access to its Postgres database. You take a
pg_dump, host it on S3 or upload directly, and FlowEngine restores the entire instance: workflows, executions, credentials, scheduling state, the lot. Closest thing to a one-click move. - Path B. Whole-instance migration between FlowEngine instances. Use this if both source and target are already on FlowEngine. The target instance is overwritten with the source's most recent backup. Useful when consolidating clients or moving someone from a shared instance to a dedicated one.
- Path C. Per-workflow JSON export and import. Use this if you are on n8n Cloud (no DB access) or only want a subset of workflows. You export each workflow as JSON inside the source n8n, then import it inside the FlowEngine n8n. Credentials reconnect by hand. Slowest but no infrastructure access required.
Most agencies migrating off self-hosted use Path A. Most people moving from n8n Cloud use Path C. Path B is internal housekeeping. The rest of this guide walks each one.
Path A: Whole-instance import from a Postgres dump
This is the cleanest move from a self-hosted n8n. The premise: every piece of n8n state lives in its Postgres database, so a database dump captures the entire instance.
1. Spin up a fresh FlowEngine instance
If you do not have one yet, follow the first-instance guide. Pick a storage tier that comfortably exceeds the size of your existing n8n database. You can resize later, but starting bigger avoids a mid-migration upgrade.
2. Take a pg_dump on the source
SSH into the host running your old n8n and run something like:
pg_dump --no-owner --no-acl \
-h localhost -U n8n -d n8n \
-F c -f /tmp/n8n-backup.dumpAdjust the host, user, and database name to match your setup. The -F c flag produces a custom-format dump (the .dump file FlowEngine expects). The --no-owner --no-acl flags strip ownership metadata so the restore does not fail on user/role mismatches.
3. Make the dump reachable
Two options:
- S3 (or any public URL). Upload the dump to a bucket and grab a presigned URL. FlowEngine fetches it server-side, so the URL only needs to be reachable from FlowEngine's infra, not from your laptop. This is the right call for dumps over a few hundred MB.
- Direct upload. If the dump is small, upload the file straight from the FlowEngine portal. Faster for ad-hoc moves.
4. Run Import Backup on the FlowEngine instance
Open the new FlowEngine instance from the Hosting sidebar. Scroll to the Advanced section, expand Migration & Import, and click the Import Backup tab.
Pick URL, paste the presigned S3 URL, click Import. FlowEngine downloads the dump, replaces the instance's database with its contents, and restarts n8n. The whole thing takes a few minutes for typical dumps and runs without your laptop staying online.
When it comes back up, every workflow, execution, credential, and schedule is in place. The instance URL is new (FlowEngine domain) but everything else is identical to the source.
Path B: Migrate between two FlowEngine instances
Same UI section, the other tab. Use this when both ends are already on FlowEngine.
From the source instance, pick the target from the dropdown, click Migrate Instance, confirm. The target's most recent backup is replaced with the source's, the target restarts, and you are done.
This is destructive: the target's existing data is gone. Use it for consolidation moves where the target was already empty or expendable.
Path C: Per-workflow JSON export and import
This is the right path for n8n Cloud (no DB access) and for cherry-picking specific workflows out of a larger source. It does not bring credentials, executions, or schedules over: only the workflow definitions themselves.
1. Spin up a FlowEngine instance
Same as Path A. First-instance guide.
2. Export each workflow from the old n8n
Open the workflow in the source n8n, click the menu icon (top right), pick Download. n8n hands you a JSON file. Self-hosted users can also bulk-export with n8n export:workflow --all --output=./workflows.json; n8n Cloud only does single-workflow downloads.
3. Import into FlowEngine
From Hosting, click into the FlowEngine instance and hit Open n8n at the top of the detail page.
Inside n8n, click Workflows in the sidebar, then the menu icon, then Import from file. Pick the JSON. The workflow appears in the list, inactive by default. Do not toggle it active yet.
4. Reconnect credentials
Open the imported workflow. Every node that uses a credential will show a red warning - the credential ID from the old instance does not exist on the new one. Click each node, open the credential dropdown, pick Create new. Reconnect using the OAuth flow or paste the API key.
This is the slowest part of Path C, especially for OAuth credentials where you have to click through the provider's consent screen. Plan ten minutes per workflow if it touches a lot of services.
One useful FlowEngine touch: any AI nodes (OpenAI, Anthropic, etc.) can use the bundled FlowEngine AI proxy instead of your own API key. One credential covers 100+ models, and budgets are tracked centrally. Worth switching during migration if you are already touching those nodes.
5. Test before activating
With credentials reconnected, hit Execute Workflow manually with a test payload. Make sure every node returns what you expect. Watch the execution log for any quietly-failing branches you would otherwise only catch in production.
Switch webhooks one at a time
Both Path A and Path C move workflows onto a new URL. If the workflow is webhook-triggered, the URL is now https://your-instance.flowengine.cloud/webhook/abc123. Update the external system (Stripe, Calendly, HubSpot, GitHub) to point at the new URL one webhook at a time so you can roll back fast if anything misbehaves.
For schedule-triggered workflows, you do not need to change anything externally. Activate the schedule on the new FlowEngine instance and deactivate it on the old one in the same minute, so the schedule does not fire twice.
Turn off the old instance only after a week
Once nothing has hit the old instance for 24 hours and your monitoring confirms the new one is healthy, stop the old instance. Do not delete it yet. Wait a week. There is always one cron-driven webhook that hits the old URL because someone forgot to update a config in a different repo.
After that week, archive or delete the old instance with confidence.
Try it
If you are sitting on a self-hosted n8n you are tired of babysitting, take a pg_dump, drop the URL into FlowEngine's Import Backup, and let the platform do the move. If you are on n8n Cloud, do the per-workflow export instead. Either way, a fresh FlowEngine instance takes about 60 seconds and you can run the old setup in parallel until you trust the new one.