This is a real migration, documented step by step. The Zap being migrated is a three-step Zapier workflow: a Typeform submission triggers a HubSpot contact creation, then a Slack notification to the sales team. A real Zap, a real Make scenario, a real 29-minute process.

The strategic case for why this migration is worth making is in the Make vs Zapier vs N8N Complete 2026 Guide. This post is the execution record.

Context: The Zap Being Migrated

The Zap had been running for 14 months. It was the primary lead capture automation for a consulting firm’s website — every Typeform submission from the contact page created a contact in HubSpot and sent a Slack message to the sales channel with the prospect’s name, company, and service interest.

The Zap ran on Zapier’s Starter plan. It had no error handling — when HubSpot’s API was briefly unavailable for 20 minutes six months prior, 11 form submissions ran through the Zap but the HubSpot contacts were never created. The Slack notifications went out (because Slack’s API was available), giving the false impression that the leads were captured. They were not.

That incident was the reason for the migration.

Approach: Screenshot to Blueprint

Step 1: Screenshot the Zap. Expanded all three steps in the Zapier editor — Typeform trigger, HubSpot action, Slack action — to show full configuration including field mappings.

Step 2: Opened Claude with the Make MCP server active. Pasted the screenshot with this prompt:

“Convert this Zapier Zap to a Make scenario. The trigger is a Typeform submission. Step 2 creates a HubSpot contact with the mapped fields. Step 3 sends a Slack message to our sales channel. Add an error handler on the HubSpot module that sends me an email alert if the contact creation fails, so we don’t lose leads silently the way we did on Zapier.”

Step 3: Claude returned a blueprint in 4 minutes. The blueprint included:

• A Webhooks > Custom Webhook module as the trigger (replacing Typeform’s native Zapier trigger — Typeform’s Make module exists but the webhook approach is more flexible and equally reliable)
• A HubSpot > Create a Contact module with field mappings from the Typeform data
• A router: Branch A sends the Slack notification on success; Branch B handles the error handler — sends an email notification with the raw submission data if HubSpot fails

The error handling structure was exactly what the client needed and had not requested explicitly in the original Zap. Claude added it based on the description of what had gone wrong.

Implementation: Import and Connect

Imported the blueprint into Make. Four connection slots needed credentials: the custom webhook (auto-created by Make, just needed the endpoint URL), HubSpot (OAuth), Slack (OAuth), and Gmail for the error alert (OAuth).

OAuth flows for HubSpot, Slack, and Gmail: 4 minutes total. Standard authorize-and-connect.

Field mapping review: Claude had mapped the Typeform field names correctly for three of the four HubSpot fields. One field — Company Size — used a different field key in Make’s HubSpot module than Zapier showed. Updated it manually in the module configuration: 2 minutes.

Slack message formatting: Claude generated a plain text Slack message. Upgraded it to a simple Block Kit layout with name, company, and service interest as labeled fields — a 3-minute edit in the Slack module.

Total connection and configuration time: 12 minutes.

Testing: Run Once With a Real Submission

Clicked “Run once” in Make. Submitted a test entry through the Typeform. Watched the execution flow in real time.

Results of the first test run:

• Webhook received the Typeform payload — green checkmark
• HubSpot contact created — green checkmark, verified in HubSpot CRM
• Slack message delivered to sales channel — green checkmark, verified in Slack
• Error handler did not fire (correct — no error occurred)

Total test time: 8 minutes including submission and verification.

Then tested the error path: temporarily invalidated the HubSpot connection (removed auth) and resubmitted the test form. The HubSpot module failed, the router took the error path, and the email alert arrived with the full submission data. Reconnected HubSpot.

Results: 60 Days Post-Activation

After 60 days running on Make:

• 237 form submissions processed — all 237 HubSpot contacts created successfully
• Two error handler triggers — both due to HubSpot API rate limiting during a high-volume day. Both sent email alerts, both were manually re-submitted within the hour, both contacts created. Zero lost leads.
• The client’s sales team noticed the improved Slack notification format — labeled fields instead of a plain text string. No change request was required; the upgrade was included in the migration.

The 11 leads lost in the original Zapier incident were not recoverable. With the error handler in place in Make, that outcome cannot recur.

Lessons Learned

Describe the failure mode, not just the workflow. The error handling structure came from describing what went wrong on Zapier — “we lost leads silently.” Claude included the appropriate error path. If the prompt had only described the happy path, the blueprint would have had only the happy path.

Webhook trigger vs. native app trigger. Claude chose a custom webhook over Typeform’s native Make module. Both work. The webhook approach is more portable — if the client switches to a different form tool, the Make scenario’s trigger doesn’t change. Worth understanding the trade-off even if you accept Claude’s recommendation.

The 29-minute total is real. This migration was not rushed. Each step was documented as it happened. The time includes screenshots, prompting, connection, testing, and the error-path test. Simple three-step scenarios migrate this fast.

Information in this article is deemed to be accurate at time of publishing. 4Spot Consulting reviews and updates content periodically as best practices evolve.