monday.com App V2 Migration: What Builders Need to Do Before May 2026

Make has released version 2 of its monday.com app connector and set a hard deadline: May 1, 2026, for all v1 instances to migrate. This isn't a soft deprecation - v1 will stop functioning. For builders using Make to orchestrate monday.com workflows, this means audit time.

The v2 release typically signals architectural improvements, API endpoint updates, or authentication mechanism changes. Without access to Make's detailed changelog, the safest assumption is that v1 relies on deprecated monday.com API layers or connection methods that Make is retiring. This is standard practice across integration platforms, but the 18-month runway is tight for complex automation stacks.

• V1 instances will cease to function after May 1, 2026 - this is a hard cutoff
• V2 likely includes updated API compatibility, authentication flows, or data handling
• Migration isn't plug-and-play - scenarios built on v1 may require reconfiguration
• The timeline suggests this is a substantial enough change that Make is giving advance notice

Start with inventory. Document every Make scenario that touches monday.com. For each one, note: what data flows in, what actions trigger in monday.com, what downstream systems depend on the output, and who owns it operationally. This is non-negotiable because v1 failure will cascade.

Next, test v2 in a sandbox. Create a duplicate scenario in v2, run it against test data in monday.com, and verify output matches v1 behavior. Pay specific attention to field mapping, date formats, user assignments, and custom fields - these are common friction points in connector migrations. Document any behavioral differences.

Finally, build a staged rollout plan. Don't flip all scenarios to v2 simultaneously on day one. Plan for December 2025 or January 2026 cutover to v2 on non-critical workflows first, validate for 4-6 weeks, then move critical automations. This gives you buffer time if v2 has edge cases your team hasn't hit yet.

• Inventory all Make scenarios using monday.com - include ownership and downstream dependencies
• Test v2 against realistic data sets in a staging environment
• Document any API differences, field mapping changes, or behavior variations
• Plan a phased migration starting Q4 2025 to avoid last-minute scrambles
• Set up monitoring on v2 scenarios to catch failures early in the rollout

Light integrations - pulling data from monday.com into a spreadsheet or triggering Slack notifications - are low-risk. These likely work with v2 without modification. Heavy integrations are where problems emerge: complex field transformations, conditional logic based on monday.com board state, multi-step workflows that depend on specific timing or data formats.

If your automations include custom JavaScript transformations, formula fields, or logic that assumes specific monday.com API response structures, v2 may require script rewrites. Similarly, if you're using deprecated authentication methods (older API keys or connection tokens), v2 will force a refresh.

Builders with mission-critical monday.com integrations should prioritize this work now rather than waiting until March 2026 when every other team is scrambling. The question to ask: how much would it cost our operation if this automation went dark for a week?

• Light integrations (data pulls, notifications) carry minimal migration risk
• Heavy integrations (conditional logic, transformations, multi-step workflows) need deeper testing
• Custom JavaScript and formula-dependent scenarios may require code updates
• Authentication mechanism changes in v2 could affect how Make connects to monday.com
• Mission-critical automations warrant early migration and extended validation windows

This migration is part of a larger trend: integration platforms tightening API contracts and retiring older connection methods. Make, Zapier, and similar platforms are shifting toward more standardized, maintainable connector architectures. V1 to V2 transitions are becoming routine as these platforms mature.

For builders, this reinforces a critical principle: automation is technical debt unless you own the integration. When you build workflows in Make that depend on monday.com, you're creating an external dependency that either platform can change. Document the integration as if you'll need to rebuild it on six months' notice. Treat connectors as maintenance items, not fire-and-forget infrastructure.

• Integration platform v1 to v2 cycles are becoming standard practice
• Builders should budget time for annual connector audits and refresh cycles
• Over-reliance on single integrations creates operational fragility - diversify where possible
• Document integration logic as if you'll rebuild it - this becomes critical during migrations