The ManyChat Migration Checklist to Run Before You Switch

This ManyChat migration checklist is the hour before the migration — the audit you run while everything is still working and nothing is at risk. The move itself is genuinely easy; we wrote up the five mechanical steps in our migration guide. What follows is what to do before step one, and it's deliberately written so it's useful even if you end up picking somebody else entirely.

Nothing here changes a setting. It's all recording and checking. Do it in an hour on a quiet morning, not at 9pm the night before a drop.

One framing worth adopting before you start: you're not moving a system, you're moving a handful of facts and a handful of decisions. The reason migrations go badly is that people try to port the machinery — every flow, every branch, every dormant experiment — when almost none of it is load-bearing. The audit below exists mostly to prove that to you with your own data.

Part 1 — record what you have

The first rule of any migration: capture the baseline before you change anything, because you cannot compare against a state you didn't write down. Every item here takes under five minutes.

1. 1Screenshot your current plan and contact count, with the date. This is your before picture. In six months, the only honest way to know whether switching helped is to compare against a number you actually recorded rather than one you remember.
2. 2Export or screenshot your last twelve invoices. Your billing history is the only pricing record that's definitionally true for you — and it's the evidence base for whether the model was actually hurting you or you just had one annoying month.
3. 3List every automation that's currently live. Not the ones you built — the ones that are on. Most accounts have a long tail of experiments still quietly running that nobody has thought about in a year.
4. 4Write down which of them actually earn. This one is manual work and there's no shortcut: ManyChat's own community has an open request to sort automations by performance, so you'll be reading them one at a time. Do it anyway — it's the most valuable item on this list.
5. 5Copy out your knowledge, not your structure. Catalog details, sizing, shipping and returns text, the FAQ answers your team trusts, your brand voice. Lift the text out of the flow nodes; you're harvesting facts and phrasings, not screenshots of the tree.

Part 2 — the checks people skip

These are the ones that turn a clean afternoon into a bad week. None are obvious, and all of them are cheaper to discover now than mid-cutover.

Check who holds your WhatsApp account

If you run WhatsApp through ManyChat, understand this before you touch anything: they hold your WhatsApp Business Account as your provider. That's not a trap anyone set for you — it's how the WhatsApp Business Platform works, and every provider in this category holds it the same way. But it means WhatsApp is a fundamentally different migration from Instagram, with its own constraints and its own timeline.

Our honest advice: don't bundle them. Sort your Instagram move first, prove the new tool on the channel where the comment-to-DM volume actually is, and treat WhatsApp as a separate project with its own plan. A migration that tries to move two channels with different mechanics on the same afternoon is a migration that goes dark on both.

Check your region before you assume a channel exists

Channel availability is not uniform, and vendors rarely lead with the gaps. ManyChat's own 2026 FAQ, to its credit, states plainly that TikTok automation is unavailable for EU and UK accounts. Whatever you're evaluating, confirm the specific channel works in your specific region on your specific account type — and do it inside a trial, not from a marketing page's channel list.

Check for a half-connected state

A genuinely nasty one, documented in ManyChat's community: Meta's Business-Manager-level connection and Instagram's own native permission grant can drift out of sync into a half-connected state that's invisible from the business side. One reported case had enabling a single new automation silently break every other automation on the account.

That's a Meta-side failure mode, not a vendor's, which means it can happen to you on the way out or on the way in. Before you migrate, disconnect and cleanly reconnect your Instagram channel on your current tool, and confirm everything still fires. If something's already half-broken, find out now — not while you're blaming the new tool for it.

Test with a real account, because test mode lies

The single best habit to carry into any migration, and it's borrowed from a solved bug in ManyChat's community: a first-step button configured as a link doesn't open Meta's message window, so the flow works perfectly in test mode and silently dies for real users. The merchant sees green. The customer sees nothing.

Test mode bypasses the platform constraints that break things in production — that's true of every vendor's test mode, ours included, because it's simulating a conversation rather than having one. So verify from a real, separate Instagram account that has never interacted with your business, on a real post. It takes ten minutes and it's the difference between finding this on a Tuesday and finding it on launch night.

Check your collaborative posts

If you run collab posts where you're tagged as collaborator rather than the original poster, test comment-to-DM on one specifically. Historically this didn't work at all in ManyChat until a fix shipped in May 2026. It's exactly the kind of edge case that's invisible until the partnership launch it breaks — ask any prospective vendor directly rather than assuming.

Part 3 — the rules for the move itself

Three rules, and the first one is the one people break.

• Run both in parallel. Nothing forces a hard cutover. Keep ManyChat connected while you teach and preview the new tool, then move the active channel when you're satisfied. The only hard constraint: don't have two tools auto-replying to the same inbox at once — pick one to own outbound while you test.
• Don't delete anything on day one. Pause ManyChat's auto-replies; don't cancel the account. Pausing is reversible, cancelling isn't, and the entire migration stays reversible right up until you cancel.
• Don't migrate during a launch week. Obvious, routinely ignored. Migrate into a boring Tuesday so that if something is weird, it's weird while the stakes are low.

Part 4 — what to watch after you cut over

The first week is where you find out what the audit missed. Watch three things specifically:

• The four automations you identified in Part 1 as the earners. If those work, the migration succeeded, whatever else is rough.
• The questions that get a bad answer. Every one is a gap in the knowledge you exported — feed it back rather than concluding the tool can't do it.
• Your contact count versus your invoice. This is the whole reason many people move, and it's the one number nobody remembers to check afterwards. Compare it against the screenshot from Part 1.

Running the ManyChat migration checklist

The technical migration is an afternoon and the ManyChat migration checklist above is an hour, and the hour is the part that matters. Record your baseline, find the handful of automations that actually earn, check the four things that break quietly, and keep the old tool paused rather than deleted until you're sure.

One thing this checklist can't save you from: if you're switching to escape outages, none of this helps, because most outages in this category are Meta's and they hit every tool identically. We read seven years of incident history to be sure of that. Switch for the pricing model or the way it answers — reasons that survive contact with reality.

When you've run the checklist, the switch page has the move itself with the channel connection built in, and the first 50 conversations a month are free with no card. If you haven't settled on a destination yet, we ranked the real options in ManyChat alternatives, ranked by what actually matters — including the cases where staying put is the right call. Meta's own platform documentation covers the permission model underneath all of this if you want the primary source.