Migrate an n8n Notion Workflow to the v3 Node's Data Source Model

Notion shipped a breaking change to its API: a database is no longer a single thing you query directly. It's now a container that holds one or more data sources, and the pages you actually want live under a data source, not the database itself. n8n's Notion node was overhauled to a new v3 to match — and the sharp edge is that database IDs are no longer accepted for database-page query or create operations. If a workflow you built a while back still points at a raw database ID once it's running on the new node version, those operations stop resolving.

The good news: for the overwhelming majority of real setups, this is a small fix, not a rebuild. Before this API version, a Notion database could only ever have one data source — so unless you've deliberately split a database into multiple sources since then, migrating just means pointing the node at "the one data source under this database" instead of the database itself.

Before you start

You'll need edit access to an existing n8n workflow that uses the Notion node against a database — Database Page operations (Get, Get Many, Create, Update) or a Notion Trigger watching a database. This is a migration for something you already have running, not a from-scratch setup.

Step 1: Confirm the node hasn't already moved

n8n versions nodes per-workflow: a workflow keeps running on whatever node version it was built with, even after a newer version ships. Nothing breaks on its own just because v3 exists — it only starts to matter once you (or a teammate) update that specific Notion node, or rebuild the workflow from scratch with a fresh node. Open the workflow and double-click the Notion node; if it's still resolving your database fine, it's on the older version and this migration is something you're doing proactively, not fixing an outage.

Step 2: Update the node to v3

With the Notion node open, look for the node-settings menu (the "..." in the node's panel) — if an update is available, it'll offer to move the node to its latest version. Confirm the update. This is the point where the node's fields actually change shape, so do it on a duplicate of the workflow first if it's anything business-critical.

Step 3: Swap Database for Data Source

This is the actual breaking change. Wherever the Database Page resource previously asked you to pick a Database — the usual n8n resource-locator field, with "From list," "By ID," and "By URL" modes — v3 asks for a Data Source instead. Switch to "From list" and pick the data source under the same database you were already using; per Step 1's caveat, that's almost always the only one listed. If you were hardcoding the old database ID as an expression, you'll need to replace it with the data source's ID the same way — a raw database ID won't resolve here anymore.

Do this for every Database Page operation in the workflow — Get, Get Many, Create, and Update all take the same field, so it's easy to fix one and miss another further down the canvas.

Step 4: Update the Notion Trigger too, if you're using one

The Notion Trigger node got the same treatment — it now also resolves against a data source rather than a database ID directly. If your workflow starts from a Notion Trigger watching for new or updated database pages, repeat Step 3's field swap there before you move on.

Step 5: Test before you save it live

Run the Notion node manually (or execute the whole workflow once against test data) before deactivating your safety copy from Step 2. Confirm pages come back with the properties you expect, and that a Create actually lands in the right place in Notion — a data source that looks right in the dropdown but was picked in a hurry is the easiest way to end up writing to the wrong list.

Tip: If you've split a single Notion database into multiple data sources — a newer Notion feature — "From list" will show more than one option, and you'll need to know which data source actually holds the pages your workflow cares about before you pick.

What's next

This is the same "audit before it bites you" pattern as a security patch, just for an API contract instead of a CVE: nothing forces you to move until you touch the node, but the fix is small if you do it deliberately rather than after something in production starts throwing errors.