Monday.com Developers Must Migrate Automation Apps by April 30, 2026
Legacy automation apps disappear from monday.com's new builders after April 30; with 18 days left, here's exactly what breaks, what to remap, and how to ship clean.

Eighteen days stand between monday.com's developer ecosystem and a hard platform cutoff. Any app still using the legacy "Integration for sentence builder" infrastructure will stop appearing in the new Automation Builder and Workflow Builder after April 30, 2026. That's not a soft deprecation or a graceful fallback: apps that miss the deadline lose marketplace visibility in the surfaces where customers are increasingly building their automations. For partner engineers, internal platform teams, and marketplace vendors, the migration is no longer a backlog item.
What Actually Breaks (And What Doesn't)
The first thing to get right is scope. Existing automations that customers have already built will continue to run during the transition; the legacy infrastructure keeps executing them. What breaks is discovery and creation: unmigrated apps will not appear when users open the new Automation Builder or Workflow Builder to create something new. If your app powers high-value enterprise workflows and your customers go to extend or clone those automations, they will not find your blocks. That's the operational risk.
The migration also does not roll back existing customer automations automatically. Because legacy automations keep running on the old infrastructure, you must keep your legacy feature endpoints and backend logic active even after you publish the migrated version. Turning off your legacy backend prematurely is a common gotcha that breaks live customer automations mid-flight.
The Core Technical Remapping
Two areas require deliberate re-implementation rather than simple configuration changes.
The first is fields. In the legacy sentence builder, input and output field types were loosely defined. The new Automation block infrastructure requires every field to be explicitly backed by a primitive type: text, number, boolean, or date. This explicit typing is what enables consistent data mapping between blocks and, critically, allows blocks to chain outputs into inputs across different automations. If your existing blocks pass freeform strings where a date or number is semantically correct, you need to retype those fields during migration, not just port them as-is. Mismatched primitives are the most common source of broken chaining in the new Workflow Builder.
The second is authentication. The legacy Authorization URL mechanism is fully deprecated. Authentication now runs through a dedicated Credentials app feature, which supports OAuth 2.0, API key patterns, and custom authentication flows. Credentials are configured separately in the Developer Center and then connected to your block and custom field app features. Practically, this means any exchange logic you built around the old Authorization URL callback flow needs to be rewritten as a Credentials endpoint. Credential IDs, not user tokens, should be returned by your credentials endpoint; tokens themselves should live in monday's encrypted secure storage and be looked up by ID at runtime. Swapping that pattern is not optional: the old auth model has no equivalent in the new infrastructure.
The Migration Workflow, Step by Step
monday.com has built a self-service migration wizard directly into the Developer Center, which handles much of the structural translation automatically. The process follows a clear sequence:
1. Open the Developer Center, select your app, and create a new draft version.
2. Navigate to the Features tab and click "Migrate" next to each legacy integration feature.
3. Review the migrated features carefully, paying particular attention to field type assignments and any authentication dependencies flagged by the wizard.
4. Rebuild or reconfigure any components the wizard flags as unsupported or requiring manual setup, such as custom auth flows and non-standard field mappings.
5. Test your migrated blocks in both the Automation Builder and the Workflow Builder to confirm they appear correctly, accept inputs, and support block chaining.
6. Publish the new version from the Developer Center.
The wizard does not guarantee a clean migration for every app. Apps with complex authorization logic, file storage integrations using managed buckets, or custom rate-limit handling in their SDK implementation will likely require manual work beyond what the wizard automates. Review the full breaking-changes list in the developer documentation before running the wizard if your app touches any of those features.
Prioritization and Customer Communication
Not all apps carry equal risk, and teams with multiple apps in the Marketplace should triage before migrating everything at once. Prioritize apps with the highest number of active automations in production, apps embedded in enterprise accounts with complex multi-step workflows, and any app where a customer's core operational process depends on your blocks running reliably. A misconfigured migration on a low-traffic internal tool is recoverable; the same mistake on an app powering a customer's order-routing automation is not.
Customer communication is a parallel track, not an afterthought. Enterprise customers with mission-critical automations need enough lead time to test flows in a sandbox environment before the April 30 cutoff. Proactively surface the timeline, share your testing plan, and make sure they know that existing automations will keep running even after the deadline. The distinction between "new automations can't be created with your app" and "existing automations stop working" is one that customer success and partner managers should convey clearly; conflating the two creates unnecessary escalations.
For rollback planning: because the legacy infrastructure continues running existing automations, your fallback if a published migration has issues is to keep the legacy backend live and communicate to customers to hold off on building new automations with the migrated blocks until the fix is deployed. There is no platform-level rollback button, so testing thoroughness in the draft version before publishing is the primary risk control.
Why the New Infrastructure Is the Foundation for What Comes Next
The migration is not just a cleanup exercise. monday.com's consolidation into a single workflows-based infrastructure is the technical prerequisite for a broader platform direction: app blocks defined once, reusable across every automation surface, including surfaces that don't exist yet. The Automation Builder and Workflow Builder are two current surfaces; the architecture is explicitly built to accommodate future ones. For partners competing with dedicated automation platforms like Zapier and Make, the ability to expose well-typed, chainable blocks natively inside monday's workflow builder, rather than requiring customers to leave the platform for external automation tools, is a meaningful distribution advantage.
The Credentials infrastructure also enables richer enterprise authentication patterns, including OAuth 2.0 flows that were awkward to implement cleanly in the old sentence-builder model. Apps that implement Credentials correctly will support the kind of seamless, IT-approved authentication that enterprise procurement teams expect, especially as monday.com pushes deeper into large accounts.
The window to ship this cleanly is narrow. Teams that complete the migration before April 30 protect their marketplace presence, preserve customer trust in production automations, and position their blocks for whatever automation surfaces monday.com builds next.
Know something we missed? Have a correction or additional information?
Submit a Tip

