Migrate Your n8n Notion Workflow to the v3 Node Data Source Model: A Step-by-Step Fix

Introduction

If your n8n workflow reads from or writes to a Notion database, a quiet breaking change may be waiting inside it. Notion changed what a database means: a database is now a container that holds one or more data sources, and the pages you actually query live under a data source, not under the database itself. n8n rebuilt its Notion node as v3 to match, and the v3 node asks for a data source where the old node asked for a database. This tutorial migrates an existing workflow to the v3 model, node by node, without breaking the production workflow it replaces.

Quick answer

Duplicate the workflow, update each Notion node to v3, replace every database ID with the data source ID under the same database, migrate the Notion Trigger the same way, then test the duplicate before switching it on.

Evidence

The change comes from Notion itself, not from n8n. Notion released API version 2025-09-03 with first-class support for multi-source databases, and its upgrade guide states plainly: “However, this change is not backwards-compatible. Most existing database connections must be updated to prevent disruptions.” The same guide explains the core rule: most API operations that used database_id now require a data_source_id, and the two types of IDs are not interchangeable. That sentence is the whole migration in one line: wherever a database ID used to work, a data source ID must now take its place.

The timing matters for planning. API version 2025-09-03 shipped in September 2025, and the n8n v3 node followed as the matching client-side change. One reassuring fact limits the blast radius: n8n versions nodes per workflow, so a workflow keeps running on whatever node version it was built with, even after a newer version ships. Nothing breaks on its own. Your workflow only needs this migration when you update its Notion nodes to v3, or when you rebuild it on the new node. That versioning is also why the safe path in this tutorial is a duplicate first, migrate second, switch over third.

For most readers, the migration is simpler than the announcement sounds. Before this API version, a Notion database could only ever have one data source. Unless a database was deliberately split into multiple sources after the change, migrating means pointing the node at the one data source under the database it already used. The work is thoroughness, not difficulty: every Database Page operation and every trigger must be checked, because fixing one node and missing another further down the canvas is the most common way this migration fails halfway.

Prerequisites

• An n8n instance (self-hosted or cloud) with a workflow that already uses the Notion node against a database.
• A Notion integration token with access to the database, or an internal integration created at notion.so/my-integrations and shared with the database page.
• Edit access to the workflow, plus permission to duplicate it for a safe test copy.
• The database ID of each affected database, or the database URL, from which the data source ID can be discovered.
• About 30 minutes, including a full test run of the migrated duplicate.

Step-by-step guide

Step 1: Inventory every affected node

Open the workflow and list every Notion node that touches a database. Check four Database Page operations, Get, Get Many, Create, and Update, and check the Notion Trigger separately. Triggers are easy to overlook because they sit at the start of the canvas, away from the operations you think of as “the Notion part.” Write the list down, with the database each node points at. If the workflow has branches, follow each branch to the end: a Create node buried in an error-handling branch counts just as much as the main-path Get Many.

Also note how each node selects its database. A node set to “From list” shows a picked database name, while a node set to “By ID” or “By URL” may carry a hardcoded database ID inside an expression. Expressions are the high-risk case in this migration, because the field label changes but the old expression keeps returning a database ID that v3 no longer accepts. Flag every expression-based selection now; Step 4 fixes them.

Step 2: Duplicate the workflow and back it up

Duplicate the workflow in n8n, and rename the copy clearly, for example by adding “v3 migration test” to its name. Deactivate the duplicate immediately if duplication copies the active state, so it cannot fire against production data while you work on it. Then export the original workflow as JSON and keep that file somewhere safe. The duplicate is your working copy; the export is your rollback. Never migrate the live workflow in place on a business-critical automation, because the node update in the next step changes field shapes, and there is no one-click undo inside the editor.

Step 3: Update the nodes to v3

Open a Notion node in the duplicate, open the node settings menu (the “…” in the node panel), and look for the option to move the node to its latest version. Confirm the update. This is the point where the node’s fields actually change shape: where the Database Page resource previously asked you to pick a Database, the v3 node asks for a Data Source instead. Repeat the update for every Notion node in the duplicate, including the trigger. Do not test anything yet. Updating the node without swapping the field value leaves the node in a half-migrated state, and its first execution will fail, which is expected at this stage, not a sign of a deeper problem.

Step 4: Find each data source ID

For each database in your Step 1 inventory, discover its data source ID using the discovery call from Notion’s upgrade guide for API version 2025-09-03. Send a GET request to the database endpoint with the new API version in the header:

curl -s "https://api.notion.com/v1/databases/YOUR_DATABASE_ID" \
  -H "Authorization: Bearer YOUR_NOTION_TOKEN" \
  -H "Notion-Version: 2025-09-03"

Read the data_sources list in the response and copy the ID of the data source your workflow uses. For a database created before the change, there will normally be exactly one entry, and it is the right one. If you prefer the app over the API, open the database in Notion, open its settings menu, and use the Copy data source ID button under Manage data sources. Record each database ID next to its data source ID in your inventory, so the swap in the next step is a lookup, not a guessing game.

Step 5: Swap Database for Data Source in every node

Work through your inventory one node at a time. In each v3 node, switch the field to “From list” and pick the data source under the same database the node was already using. For nodes that used “By ID” with an expression, replace the expression’s database ID with the data source ID, keeping the same expression structure around it. The n8n Notion node documentation describes the node’s current operations and parameters, and it is the right place to confirm a parameter name if a field looks unfamiliar after the update.

Apply the same swap to the Notion Trigger node, which now resolves against a data source rather than a database ID directly. Then re-check the list: Get, Get Many, Create, Update, and trigger, every one of them, with no node left pointing at a database. A useful final check is to search the duplicate workflow’s JSON export for the old database IDs. Any remaining occurrence is a node you missed, or an expression in a downstream node that passes the old ID along.

Step 6: Test the duplicate end to end

Run the duplicate manually with a test record, not with production data. For a read path, confirm Get Many returns the same rows and properties as before, including any property the workflow filters or maps downstream. For a write path, create a test page through the duplicate, confirm it lands in the right data source with the right properties, then delete the test page. For an update path, change a test page’s property through the duplicate and confirm the change appears in Notion. If the workflow has a trigger, test it by changing a page in the data source and confirming the duplicate fires. Only when every path passes do you deactivate the original workflow and activate the duplicate, or copy the migrated nodes back into the original if your team prefers to keep the original’s execution history.

Troubleshooting

The node still fails after the update, with a resolution error

This almost always means one field still carries a database ID. Reopen the failing node and check the Data Source field itself, then check any expression feeding into it: an expression like {{ $json.database_id }} that upstream still populates from an old source will silently hand v3 a database ID. Replace the value with the data source ID from Step 4, or change the upstream node to emit the data source ID. Re-run the node alone before running the whole workflow, so you know exactly which node was at fault.

The trigger never fires, but manual operations work

The trigger was migrated separately, or not at all. Open the Notion Trigger node in the duplicate and confirm its field now points at a data source, not a database. Also confirm the trigger watches the right data source when a database has more than one: a trigger pointed at a second, rarely written data source will look dead while the main source changes constantly. After fixing the trigger, make a small test change in the correct data source and watch for the execution.

The node cannot list the data source, or shows an empty list

This is usually a permissions problem, not a migration problem. The Notion integration must be shared with the database page that contains the data source. Open the database in Notion, open its connections menu, and confirm your integration is listed. If it is missing, add it, then return to n8n and refresh the field’s list. If the list still comes back empty, verify the credential in n8n: re-entering the integration token and saving the credential forces a fresh connection, and it catches tokens that were rotated or revoked.

The workflow picks the wrong data source in a multi-source database

When a database was split into several data sources, “From list” shows more than one entry with similar names, and picking the wrong one reads or writes the wrong schema. Open each candidate data source in Notion and compare its properties with the properties your workflow maps: the correct source is the one whose property names match the workflow’s field mappings. If two sources share property names, check a sample page in each source to see which one holds the records your workflow is meant to process, then pin that source explicitly rather than relying on list order.

Executions pass but downstream nodes see missing properties

A data source can carry a different property set than the database view the old node returned, especially after a split. Compare the output JSON of a migrated Get Many node with a saved output from the old node, field by field. Where a property name changed or a property moved, update the downstream mapping to the new path instead of assuming the old path still resolves. This check is worth doing even when the run shows green, because a silently empty field can corrupt a CRM or spreadsheet row far downstream before anyone notices.

FAQ

See the front matter FAQ for the questions readers ask most: why a workflow stops after the v3 update, whether a still-working workflow needs migrating, where to find a data source ID, whether the trigger needs migrating, how to handle multi-source databases, and how to roll back.

Conclusion

The v3 migration is a field swap, repeated carefully across every node, not a rewrite. Duplicate the workflow, update the nodes, replace database IDs with data source IDs, migrate the trigger in the same pass, and prove the duplicate with a real test run before it takes over. For the bigger picture, our complete n8n guide covers installing, scaling, and securing an instance, and our n8n 3.0 upgrade guide walks the wider breaking-change checklist this migration sits inside. If you run Notion automations at any scale, do the inventory in Step 1 this week: the nodes that still work today are the ones that will surprise you the day you update them.

Frequently asked questions