How to Create a Migration Playbook from Make.com to Native SaaS Integrations

Your enterprise prospect just finished a great software evaluation. They love your product's core functionality. The UI is exactly what their team needs. Then they ask the inevitable question: "How does this connect to our Salesforce instance?"

You point them to a Make.com scenario template or a Zapier link. The deal stalls. The internal champion ghosts you. Six weeks later, procurement picks the competitor with native Salesforce sync built directly into their settings page.

If your B2B SaaS product is still pointing enterprise customers at a visual workflow builder to handle CRM, HRIS, or ERP syncs, you have a finite runway before that architectural decision starts costing real ARR. Early-stage SaaS teams often use Make.com or Zapier to prototype integrations quickly. These are exceptional platforms for internal operations and citizen developers. But as your product moves upmarket, relying on visual workflow builders for multi-tenant data sync becomes a severe architectural liability.

This playbook is a highly structured, risk-free architectural and operational guide for senior product managers and engineering leaders. We will cover exactly how to migrate your customer-facing integrations off an embedded iPaaS or visual workflow builder onto a dedicated, declarative unified API platform—without causing downtime or forcing your customers to reconnect their accounts.

What Happens When You Switch Unified API Providers

The short answer: nothing has to break. The longer answer is that four specific components are at risk during any integration provider migration, and each one needs a deliberate plan.

OAuth connections. Your customers authorized your application to access their CRM, HRIS, or ERP accounts. Those authorizations produced OAuth tokens that your current provider stores. If you can extract those tokens and inject them into the new provider, your customers never need to reconnect. If you cannot extract them, every customer sees a "Reconnect" prompt - the single biggest source of migration churn.

Data mapping schemas. Every field mapping, query translation, and response transformation you built in your current provider needs an equivalent in the new one. Missing a single custom field mapping means corrupted or incomplete data for the customers who depend on it.

Webhook subscriptions. If your current provider registered webhook endpoints with third-party APIs (Salesforce, HubSpot, etc.), those subscriptions point at your old provider's URLs. You need to either re-register them against the new provider or run a dual-receive pattern during cutover.

In-flight data. Sync jobs, queued webhook events, and pending API calls that are mid-execution during the switch need a drain plan. You cannot simply flip a switch and hope nothing was in the pipeline.

The rest of this playbook walks through each risk with prescriptive checklists, timelines, and rollback criteria so your engineering and support teams can execute a migration with minimal ambiguity.

When to Migrate

Not every frustration with your current integration layer warrants a full migration. Migrate when at least two of these conditions are true:

• Margin pressure. Your iPaaS costs grow linearly with customer API usage, and integration infrastructure now exceeds 15% of your per-customer COGS.
• Enterprise deals blocked. You have lost or stalled two or more enterprise deals in the past two quarters because prospects rejected your integration approach during security or architecture review.
• Maintenance burden. Your engineering team spends more than 30% of integration-related effort on maintaining existing connectors rather than building new ones.
• Customization ceiling. You cannot support per-customer field mappings or custom objects without code deployments.
• Scale wall. You are approaching rate limit ceilings, operation quotas, or concurrency limits on your current provider with no clear path to scale.

The MVP Trap: When Make.com and iPaaS Prototypes Break at Scale

Visual workflow builders solve the "zero to one" integration problem brilliantly. You drag a webhook trigger, connect it to a Salesforce module, map some fields visually, and you have a working integration in an afternoon.

But building an integration is only 20% of the work. The other 80% is maintaining it across hundreds of tenants, dealing with API deprecations, handling rate limits, and managing custom fields.

The Margin-Killing Reality of Operation-Based Pricing

Visual workflow builders like Make.com price per operation. Every step in a visual graph consumes a task credit. This means your infrastructure costs scale linearly with your customers' API usage.

Imagine a mid-market customer signs up and wants to sync their historical HubSpot data into your platform. They have 250,000 contacts. If your iPaaS charges $0.01 per task, and your workflow requires three steps per contact (fetch, transform, load), that single historical sync just cost you $7,500. If your SaaS product charges $500/month, that one sync wiped out your margin for the entire year.

The App Sprawl and Technical Debt Crisis

According to Zylo's 2025 SaaS Management Index, which analyzed $40 billion in software spend, the average tech company now pays for 275 SaaS applications. This app sprawl creates a massive integration backlog for B2B SaaS vendors.

When you use visual builders to handle this volume, you end up with hundreds of disconnected visual graphs. There is no version control, no centralized error handling, and no easy way to roll back changes. Industry analysis highlights that engineering teams often spend up to 40% of their capacity maintaining yesterday's shortcuts and integration technical debt rather than building core product features.

B2B buyers prioritize native integrations. Research indicates that 63% of SaaS companies invest in integrations specifically to improve customer retention and unlock expansion revenue. Pointing a CIO to a Make.com template signals that your product is not enterprise-ready.

The Architectural Shift: Moving to a Declarative Integration Layer

Migrating off an iPaaS requires a fundamental shift in how you think about integration architecture.

Most unified API platforms and embedded iPaaS tools solve the integration problem with brute force. Behind their "unified" facade, they maintain separate code paths for each integration. They have hardcoded business logic that must be updated every time an API changes. Adding a new integration means writing new code, deploying it, and hoping it doesn't break the existing integrations.

Truto takes a radically different approach. The entire platform executes zero integration-specific code. The same code path that handles a HubSpot CRM contact listing also handles Salesforce, Pipedrive, Zoho, and Close—without knowing or caring which one it is talking to.

Integration-specific behavior is defined entirely as data: JSON configuration blobs describing the API, and JSONata expressions describing the data transformations.

graph TD
    subgraph Legacy iPaaS Architecture
        A[SaaS App] --> B(Visual Workflow Builder)
        B --> C{Provider Switch}
        C -->|If Salesforce| D[Salesforce Node]
        C -->|If HubSpot| E[HubSpot Node]
        C -->|If Pipedrive| F[Pipedrive Node]
    end

    subgraph Declarative Unified API Architecture
        G[SaaS App] --> H(Generic Execution Engine)
        H --> I[(Integration Config JSON)]
        H --> J[(JSONata Mapping Expressions)]
        I -.-> K[Third-Party API]
        J -.-> K
    end

This is not an incremental improvement. It is an architectural category difference. Adding a new integration is a data operation, not a code operation. This zero integration-specific code approach is what allows you to scale to hundreds of integrations without expanding your engineering headcount.

Pre-Migration Audit Checklist

Before writing a single line of migration code, your team needs a complete inventory of your current integration state. This audit typically takes 3-5 days for a small deployment and up to two weeks for a large one.

1. OAuth Token Ownership

• Confirm you own the OAuth app registrations (client ID and client secret) for every third-party provider. If your iPaaS created these on your behalf, you may not control the credentials.
• Verify that your current provider allows exporting raw access_token, refresh_token, and expires_at values. Test this with a single account before planning the full migration.
• Identify which integrations use OAuth 2.0 (portable tokens) vs. API keys (usually simpler to migrate) vs. session-based auth (may require re-authentication).
• Count the total number of connected accounts per integration, per customer. This is your migration scope.

2. Schema and Field Mapping Inventory

• Export or document every field mapping in your current provider. For each integration category (CRM, HRIS, ATS, etc.), catalog the unified fields, the source fields, and any transformation logic applied.
• Flag every custom field mapping. These are the highest-risk items during migration because they are tenant-specific.
• Document any conditional logic (if/then branches, filters, routers) in your current workflows. Each one needs an equivalent JSONata expression or configuration in the new provider.

3. Webhook Configuration Inventory

• List every webhook subscription your current provider registered with third-party APIs. Note the endpoint URL, event types, and any signing secrets.
• Determine whether your current provider or the third-party API owns the subscription lifecycle. Some providers register webhooks on your behalf and deregister them if you cancel.
• Identify which webhooks are account-specific vs. environment-wide (fan-out).

4. Rate Limit Budget Analysis

• Document the rate limits for every third-party API you integrate with. Note the quota (requests per window), window duration, and current utilization.
• Calculate whether running two providers in parallel during cutover will exceed any rate limit. If so, stagger the migration by category or throttle the old provider during the parallel-run phase.

5. Sync Job and Scheduled Task Inventory

• List every recurring sync job, its schedule, its scope (full sync vs. incremental), and the average record count per run.
• Identify which sync jobs write data back to third-party APIs (bidirectional sync) vs. read-only pulls. Bidirectional syncs carry higher risk during migration because duplicate writes can corrupt data.

6. Customer Communication Plan

• Identify which customers (if any) will experience visible changes. If the migration is fully transparent (no reconnection required), communication is optional but builds trust.
• Prepare a rollback communication template in case you need to revert mid-migration.

Step 1: Extracting OAuth Credentials and Managing the Authentication Handoff

The most terrifying part of migrating integration providers is the authentication handoff. If you do this wrong, you have to email your entire customer base asking them to click "Reconnect" on their Salesforce or QuickBooks accounts. This causes immediate churn and damages trust.

To execute a zero-downtime migration, you must programmatically extract the OAuth tokens from your iPaaS and inject them into your new unified API infrastructure.

The Extraction and Injection Process

1. Audit your current token state: Export the active access_token, refresh_token, and expires_at timestamps from your current provider. Some legacy iPaaS tools obscure these; you may need to contact their support to get a raw database dump.
2. Map to the unified context schema: Truto stores credentials in a generic context JSON object attached to an Integrated Account record. You will format your exported tokens to match this schema.
3. Inject via API: Use Truto's Admin API to programmatically create the Integrated Accounts, passing the credentials directly into the context.

// Example: Injecting extracted Salesforce credentials into Truto
{
  "integration_name": "salesforce",
  "environment_id": "env_12345",
  "tenant_id": "customer_org_99",
  "context": {
    "oauth": {
      "token": {
        "access_token": "00Dxx0000001gER!AQEAQ...",
        "refresh_token": "5Aep861...",
        "expires_at": "2026-10-15T14:30:00Z"
      }
    },
    "instance_url": "https://na139.salesforce.com"
  }
}

Proactive Token Management

Once injected, Truto takes over the lifecycle management. The platform checks token expiration windows before every API call. If a token is within 30 seconds of expiring, the engine proactively executes the refresh flow. Additionally, the system pre-schedules refresh work 60–180 seconds before expiry to ensure high availability.

If a refresh fails (e.g., the user revoked the app in Salesforce), the account is marked as requiring re-authentication, and a webhook event is fired to your backend so you can prompt the user in your UI.

For a deeper dive into this exact sequence, review our guide on switching providers without downtime.

Step 2: Replicating iPaaS Logic with JSONata Mappings

In a visual workflow builder, data transformation looks like a tangled web of routing nodes, string manipulation blocks, and conditional branches. To migrate, you must translate this visual spaghetti into clean, declarative JSONata expressions.

JSONata is a functional query and transformation language for JSON. It is Turing-complete, side-effect free, and purpose-built for reshaping JSON objects. Truto uses it as the universal transformation engine. Every field mapping, query translation, and conditional logic block is a JSONata expression stored as a string in the database.

Transforming Responses

Let us look at how you migrate a complex CRM contact mapping. Your iPaaS might have ten different nodes to handle custom fields, flatten nested objects, and format dates. In Truto, this becomes a single, highly readable JSONata expression.

// Truto JSONata Response Mapping for a CRM Contact
(
  $phone_numbers := $filter(phoneNumbers, function($v) { $v.type = "primary" });
  {
    "id": id,
    "first_name": properties.firstname,
    "last_name": properties.lastname,
    "email": properties.email,
    "phone": $count($phone_numbers) > 0 ? $phone_numbers[0].number : null,
    "created_at": $replace(properties.createdate, "+0000", "Z"),
    "company_id": associations.companies.results[0].id,
    "raw_data": $
  }
)

Transforming Requests and Queries

The mapping layer works bidirectionally. When your SaaS application makes a request to Truto's unified API (GET /unified/crm/contacts?status=active), Truto uses JSONata to translate that query into the specific third-party format.

For example, translating status=active might result in filter [status]=Active for one API, or a complex SOQL WHERE clause for Salesforce. The runtime engine does not care what the JSONata expression does; it simply evaluates it and constructs the HTTP request.

Step 3: Handling API Quirks (Rate Limits, Pagination, and Webhooks)

The mark of a senior engineering team is how they handle the inevitable failures of third-party systems. Visual workflow builders often abstract these failures away poorly, leading to silent data loss or infinite retry loops that get your IP banned.

Transparent Rate Limiting

Many unified APIs attempt to be "smart" by automatically absorbing and retrying rate limit errors. This is an architectural anti-pattern. If an upstream CRM is returning HTTP 429 (Too Many Requests), your backend needs to know about it so it can pause its own internal sync queues. If the unified API hides this, your workers will continue burning CPU cycles pushing data into a black hole.

Truto enforces a radically transparent approach to rate limiting. When an upstream API returns a 429, Truto passes that exact error directly back to the caller.

However, Truto normalizes the rate limit information into standardized HTTP headers per the IETF specification:

• ratelimit-limit: The total request quota.
• ratelimit-remaining: The remaining requests in the current window.
• ratelimit-reset: The timestamp when the quota resets.

Your application retains complete control over its retry and exponential backoff strategies, armed with normalized data regardless of whether the upstream API uses headers, JSON bodies, or custom formats to communicate its limits.

Declarative Pagination

Pagination logic is notoriously fragmented across SaaS APIs. Some use cursor-based pagination, others use offsets, and some rely on HTTP Link headers.

Truto handles this declaratively. The integration configuration defines the pagination format (cursor, page, offset, link_header). When you call a unified list endpoint, Truto applies the correct strategy automatically, extracting the next page token from the response and returning a standardized next_cursor to your application.

Unified Webhook Ingestion

Moving off an iPaaS means you need a new way to ingest real-time events. Truto acts as a unified webhook receiver. When a third-party service fires a webhook, Truto executes a precise pipeline:

1. Verification: Validates the cryptographic signature (HMAC, JWT, Basic Auth) using timing-safe comparisons.
2. Payload Transform: Applies a JSONata expression to normalize the raw payload.
3. Event Mapping: Translates provider-specific events (e.g., employee.joined) into standardized unified events (e.g., record:created on hris/employees).
4. Enrichment: Optionally fetches the full resource data if the webhook payload only contained an ID.
5. Delivery: Enqueues the normalized event for delivery to your configured endpoints.

This pipeline supports both account-specific webhooks and environment-level fan-out architectures, ensuring you receive a consistent payload shape regardless of the source.

Step 4: Supporting Per-Customer Customizations with the 3-Level Override Hierarchy

The most common reason enterprise deals stall is custom fields. Your prospect uses Salesforce, but they have heavily modified their Account object with custom fields specific to their industry. Your hardcoded iPaaS template expects standard fields and breaks.

If you use a traditional unified API, you are forced to map these custom fields into a generic remote_data blob, pushing the parsing logic back onto your application code.

Truto solves this via a 3-Level Override Hierarchy. This system allows you to customize API mappings on a per-customer basis without touching source code.

Level 1: Platform Base

This is the default mapping provided by Truto. It translates standard Salesforce fields to the unified CRM model. It works perfectly for 80% of your customers.

Level 2: Environment Override

You can apply overrides at the environment level (e.g., Staging vs. Production). If your staging environment needs to route requests to a sandbox API endpoint, you apply a JSONata override here. It deep-merges on top of the Platform Base.

Level 3: Account Override

This is the breakthrough feature for enterprise sales. Individual connected accounts can have their own mapping overrides.

If "Enterprise Corp" needs their custom x_industry_type_c Salesforce field mapped to your application's vertical field, you simply apply a JSONata override directly to their Integrated Account record.

// Account-level override for Enterprise Corp
{
  "response_mapping": {
    "vertical": "x_industry_type_c"
  }
}

The runtime engine deep-merges this override at execution time. Only Enterprise Corp's data is affected. You just solved a custom enterprise integration requirement without deploying a single line of code. For more details on this architecture, read our guide on per-customer API mappings.

Parallel-Run Architecture and the Dual-Receive Pattern

The safest way to migrate between integration providers is to run both systems simultaneously for a defined period, compare their outputs, and cut over only when the new provider matches the old one within your tolerance thresholds. This is a well-established practice in zero-downtime migrations - incremental, phased deployment that minimizes risk and allows continuous monitoring.

The Dual-Receive Pattern for Webhooks

During the parallel-run phase, both providers need to receive webhook events from the same third-party sources. There are two approaches:

Option A: Dual subscription. Register webhook endpoints for both providers with the third-party API. Both receive the same events independently. This is the simplest approach but doubles your webhook volume and may trigger rate limits on providers that throttle subscription counts.

Option B: Fanout proxy. Deploy a lightweight HTTP proxy that receives webhooks from third-party APIs and forwards each payload to both providers. This keeps a single subscription per source but adds an infrastructure dependency.

graph LR
    A[Third-Party API] -->|webhook| B(Fanout Proxy)
    B -->|forward| C[Old Provider]
    B -->|forward| D[New Provider]
    C -->|deliver| E[Your Backend]
    D -->|deliver| E

Your backend receives events from both providers during the parallel-run window. Tag each event with its source so you can compare payloads and detect discrepancies.

Shadow Mode for API Calls

For unified API calls (list, get, create, update), run the new provider in shadow mode:

1. Your application sends every API request to your old provider as normal.
2. A background process replays the same request against the new provider.
3. A comparison job diffs the responses and logs any field-level discrepancies.

Parallel-Run Duration

Run the parallel phase for a minimum of one full business cycle per integration category. For most B2B integrations, that means at least one full week to capture weekday and weekend patterns. For payroll or monthly reporting integrations, run for a full calendar month.

Category-by-Category Cutover Checklist

Never migrate all integration categories simultaneously. Cut over one category at a time, starting with the lowest-risk one.

Recommended Cutover Sequence

1. Read-only integrations first. Categories where your product only reads data (e.g., pulling contacts from a CRM) carry the lowest risk because a bad mapping only affects display, not third-party data.
2. Low-volume categories second. Integrations with fewer connected accounts and lower API call frequency give you more room to catch and fix issues.
3. Bidirectional sync last. Categories where your product both reads and writes data (e.g., creating deals in a CRM, updating employee records in an HRIS) carry the highest risk and should only move after you have built confidence with the earlier categories.

Per-Category Steps

For each integration category, execute the following sequence:

• Complete the parallel-run for this category with zero critical discrepancies for the required duration.
• Freeze schema changes on the old provider for this category. No mapping updates during cutover.
• Drain in-flight work. Wait for all pending sync jobs and queued webhook events on the old provider to complete.
• Switch routing. Point your application's API calls for this category to the new provider.
• Verify webhook delivery. Confirm the new provider is receiving and delivering webhook events for this category within your latency SLA.
• Run parity validation against live data for at least 24 hours.
• Deregister old webhook subscriptions for this category only after the validation window passes.
• Mark category as migrated in your internal tracking.

Go/No-Go Criteria

Define these before you start. A category is ready for cutover when:

• Parallel-run parity score is above 99.5% for response shape and field values.
• Zero sustained authentication failures on the new provider for accounts in this category.
• Webhook delivery latency on the new provider is within 2x of the old provider's baseline.
• At least one full business cycle of shadow mode data has been reviewed and approved.

Validation Checks and Parity Tests

Parity testing is the difference between a confident migration and a prayer. Run these checks during the parallel-run phase and again immediately after each category cutover.

Response Shape Validation

For every unified API endpoint in the migrating category, compare the response schema from both providers:

• Same top-level fields present in both responses.
• Same data types for each field (string vs. number vs. array).
• Same pagination behavior (next_cursor format, page sizes, total counts).
• Same null vs. absent field behavior for optional fields.

Field-Level Data Parity

For a statistically meaningful sample of records (minimum 500 or 10% of total records, whichever is larger):

• Compare field values between old and new provider responses for the same third-party record.
• Flag any field where values differ. Investigate whether the difference is a mapping error, a data freshness issue, or an intentional improvement in the new mapping.
• Pay special attention to: date/time formats and timezone handling, enum values (string casing, naming conventions), phone number formatting, and custom field handling.

Webhook Payload Parity

For every webhook event type in the migrating category:

• Compare the normalized payload structure from both providers.
• Verify that event type names match your application's expected values.
• Confirm that timestamps, record IDs, and changed fields are present and correctly formatted.

Error Handling Parity

Deliberately trigger common error conditions and compare how both providers surface them:

• Invalid or expired OAuth token (expect 401).
• Rate limit exceeded (expect 429 with normalized headers).
• Nonexistent record ID (expect 404).
• Malformed request body (expect 400 with a descriptive error message).

Testing with Live Accounts

Do not rely solely on sandbox accounts. Test with at least 3-5 live production accounts per integration (with the customer's consent) during the parallel-run phase. Sandbox environments frequently behave differently from production - different rate limits, different field configurations, different data volumes. Your parity tests need to reflect reality.

Rollback and Contingency Plan

Define your rollback plan before the migration starts. If you wait until something breaks to figure out how to revert, you will make the situation worse under pressure.

Rollback Triggers

Agree on these with your engineering and support teams before cutover begins. Initiate a rollback if any of the following occur during the validation window:

• Authentication failure rate for the migrated category exceeds 5% of connected accounts.
• Webhook delivery success rate drops below 95% for more than 30 minutes.
• More than 3 customer-reported data discrepancies within the first 24 hours.
• Any data corruption in a bidirectional sync (duplicate records created, fields overwritten with incorrect values).

How to Roll Back

• Re-route your application's API calls for the affected category back to the old provider.
• Re-enable webhook subscriptions on the old provider if you deregistered them.
• Drain any queued events on the new provider to prevent duplicate delivery when you eventually re-migrate.
• Audit the affected time window: identify every API call and webhook event that was processed by the new provider during the failed cutover, and verify data integrity in your application's database.

Keep the Old Provider Warm

Do not cancel your old provider's account or delete its configuration until every category has been migrated and validated for a minimum of 30 days. The cost of maintaining a dormant account is trivially small compared to the cost of an unrecoverable rollback.

Sample Migration Timelines

These estimates assume a team of 2-3 engineers working on the migration and include the parallel-run phase. Actual timelines vary based on the complexity of your custom mappings and the number of bidirectional sync integrations.

Monitoring and Metrics During Cutover

Instrument your application and the new provider's API with the following metrics before you begin the first category cutover. If you do not have baseline numbers from your old provider, measure them during the parallel-run phase.

Build a migration dashboard that surfaces these metrics per category and per integration. Review it at the start and end of each business day during active cutover periods.

Post-Migration Postmortem Checklist

After every category has been migrated, validated, and stable for 30 days, run a formal postmortem. This captures institutional knowledge and surfaces integration debt that accumulated during the migration.

Decommission the Old Provider

• Cancel or downgrade your old provider's account.
• Remove old provider SDK dependencies from your codebase.
• Delete old provider webhook endpoints from third-party API dashboards.
• Archive (do not delete) old provider configuration and mapping documentation for reference.

Validate Cost Impact

• Compare monthly integration infrastructure cost (old vs. new) for at least two full billing cycles.
• Calculate the actual per-customer integration cost under the new provider.
• Verify that high-volume sync operations (historical imports, bulk exports) no longer produce cost spikes.

Update Documentation

• Update internal runbooks to reference the new provider's APIs, dashboards, and support channels.
• Update customer-facing integration documentation and setup guides.
• Update your status page to reflect the new provider's dependency.

Capture Lessons Learned

• Document every mapping discrepancy found during parity testing and how it was resolved.
• Record the actual migration timeline vs. the estimated timeline, with reasons for any overruns.
• Note any third-party API quirks discovered during migration that should inform future integration work.
• Identify which parts of the migration could be automated for future environment or region migrations.

The ROI of Migrating: Reclaiming Engineering Capacity

Migrating off a visual workflow builder is a strategic infrastructure upgrade. The return on investment is measured in three distinct categories:

1. Margin Protection: By eliminating operation-based pricing models, your infrastructure costs scale predictably with your compute usage, not linearly with your customers' API traffic. You can confidently support high-volume historical data syncs without destroying your unit economics.

2. Engineering Velocity: Reclaiming the 40% of engineering capacity spent maintaining visual workflow technical debt allows your team to focus on core product features. Adding a new integration becomes a configuration task, not a sprint commitment.

3. Enterprise Revenue Unblocked: When a CIO asks how you integrate with their heavily customized ERP or CRM, you no longer point them to a Zapier link. You offer a native, white-labeled integration experience that handles their custom fields flawlessly, passes their security review, and keeps them fully within your application's UI.

The migration requires discipline, specifically around the OAuth credential handoff and translating visual logic into JSONata. But once the declarative architecture is in place, your integration layer transforms from a fragile liability into a massive competitive advantage.