How to Migrate AffinityQuest Records to Salesforce NPSP with Data Loader
AffinityQuest to Salesforce NPSP migration guide using Data Loader. Learn field mapping, ISO 8601 dates, and stage picklist transforms for nonprofits.
Checklist: migrate Make.com scenarios for monday.com API (legacy → v2)
Your monday.com Make API migration checklist: inventory affected scenarios, run a pilot, bulk-update with find/replace, and roll back if anything breaks.
TABLE OF CONTENTS
If your monday.com scenarios in Make suddenly start throwing module deprecation warnings, it usually means you are still using the legacy monday.com app in Make. This checklist walks you through a safe, repeatable way to migrate scenarios from the legacy monday.com modules to the v2 modules, including a bulk-edit workflow, a risk checklist, and a rollback plan.
What changed (and why this matters)
Make deprecated the legacy monday.com app in 2026, with a May 1 cutoff for v1-to-v2 migration. If your scenarios are still on v1 modules, they may already be erroring — migrate immediately.
Scenarios still relying on legacy monday.com modules may have stopped working or started erroring. This checklist walks you through fixing them.
Before you touch anything: quick safety checklist
Duplicate the scenario (or clone it) so you have a clean rollback point.
Turn scheduling off while you migrate, or add a temporary filter that prevents writes.
Export a blueprint of the scenario.
Identify which scenarios are client-critical and migrate those first.
Check if any modules use fields that might have changed names or meaning.
Step 1: inventory which scenarios need migration
- In Make, search for scenarios that show warnings like:
- “Upgrade module”
- “There is a new version of the monday.com (legacy) app available”
- Make a short list of:
- Scenario name
- How often it runs
- Whether it writes to monday.com (creates or updates items)
- The count of monday.com modules inside the scenario
Step 2: do one “pilot scenario” first
Pick a scenario that is:
- important enough to be a real test
- low-risk enough that an outage will not be catastrophic
Your goal is to learn the migration pattern once, then apply it everywhere.
Step 3: migrate monday.com modules (manual method)
In the scenario editor:
- Click each monday.com (legacy) module.
- Replace it with the monday.com v2 version of that module.
- Reconnect the module if needed, then remap fields.
monday.com module migration notes
When migrating monday.com modules, the team has seen cases where:
- the module name needs a “B2” suffix
- the module’s version setting needs to be set to 2
Watch for these when remapping.
Step 4: bulk-update faster using a copy/paste + find/replace workflow
If you have lots of scenarios to migrate, clicking and remapping each module manually gets painful.
A faster workflow that has worked for our team:
- Copy the module configuration or the scenario blueprint snippet for a monday.com module.
- Paste it into a code editor.
- Use find/replace to update the repeated legacy fields.
- Paste the updated version back into Make.
Find/replace patterns to look for
Your exact strings will vary, but common targets include:
- legacy module identifiers
- version fields
- module name patterns
Always test this workflow on a cloned scenario first. A bad find/replace can silently break mappings.
Step 5: don’t forget HTTP modules (if your scenarios use them)
Some Make scenarios use HTTP modules alongside monday.com.
If you see HTTP modules that are also deprecated, your migration may include an HTTP module version bump, too. The team has seen cases where an HTTP module migration required changing:
- version 3 → version 4
- a model setting from “send data” to “make request”
Step 6: test strategy (minimum viable)
For each migrated scenario:
Run once manually with a known-good input
Confirm the monday.com item/board updates as expected
Confirm error handling routes still work
Confirm rate limits are not being hit
Re-enable scheduling
Step 7: rollout plan for multiple scenarios
- Migrate in batches.
- Start with scenarios that run least frequently.
- Move to client-critical scenarios once your pattern is proven.
- Keep notes on what changed so you can repeat it quickly.
Rollback plan
If something breaks:
- Turn scheduling off.
- Revert to the cloned scenario.
- Re-enable scheduling on the clone.
- Revisit the migrated scenario to identify which module mapping caused the issue.
FAQ
Is there a fully automated migration tool?
As of now, most teams migrating at scale are still doing it by replacing modules and remapping. The best way to reduce time is to standardize your approach and use a bulk-edit workflow like copy/paste plus find/replace.
Should I migrate everything at once?
No. Migrate in batches so you can catch issues early without creating a large outage window.
Get help migrating your Make scenarios
Migrating Make scenarios from legacy monday.com modules usually breaks at the remapping step — fields that looked identical behave differently in v2, and a single bad find/replace can silently break mappings across dozens of scenarios. If you've hit that wall, book a ZoomFlow session — one of our consultants can debug it with you live and get your scenarios running on v2 in the same call.
Related Posts
Encircle + Dash Integration: Automate Restoration Job Data
Learn how to sync Encircle and Dash to eliminate double entry on restoration jobs—automating job creation, documentation sync, and field-to-office data flow.
How to Grant Notion Integration Permissions Safely (Without Making Someone an Admin)
Notion integration permissions can be secure without admin access. Use this least-privilege checklist to scope tokens, capabilities, and page connections.
