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.

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.

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.

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.