How to switch scheduling tools without breaking your existing links

Nobody hesitates to switch schedulers because configuring a new one is hard. They hesitate because a booking link is load-bearing infrastructurethat has escaped into the wild: it's in your email signature, your LinkedIn bio, a conference speaker page, three Notion docs, a customer's CRM record, and an automated sequence someone built in 2024 and left the company.

The good news is that the migration risk is almost entirely a link management problem, not a data problem — and link management has a clean solution: don't cut over. Run both tools in parallel and let the old links drain.

First, the honest part: there is no importer

Neos Meet has no automated Calendly importer. Not “coming soon” in a way that means next week — it does not exist, and this guide describes a manual rebuild. We'd rather say that here than have you discover it after signing up.

The reason it stings less than it sounds: a scheduler is mostly configuration, and there isn't much of it. A typical person has one to three event types, one weekly availability pattern, and a couple of buffer rules. Rebuilding that is a matter of minutes, and our setup assistant will take a plain-English description (“30-minute demo, weekday afternoons only, 15-minute buffer after”) and propose the event types and hours for you to approve. The step-by-step version with timings walks the whole thing.

What genuinely does not transfer, from any tool to any other tool: your existing scheduled meetings, your historical booking data, and your old links. Plan around those three and the rest is typing.

The migration principle: parallel run, never a cutover

A cutover — delete the old links, publish the new ones, hope — creates a window where someone clicks a dead URL and simply doesn't book. A parallel run has no such window:

1. Set up the new tool completely while the old one keeps taking bookings. Nothing is at risk yet.
2. Switch what you control — signature, bio links, docs, templates — to the new link. New traffic goes to the new tool from this moment.
3. Leave old links live. Anything already scheduled in the old tool stays there and plays out normally, with its own reminders and its own calendar invites.
4. Watch the old tool's inbound volume decay. When a week passes with no new bookings from it, the long tail has drained.
5. Then cancel — or, for most annual contracts, simply stop renewing.

The link inventory nobody makes (make it)

Twenty minutes with a text file saves a month of “why did nobody book?”. Search for your old scheduling domain everywhere you can:

• Email signature — yours, and the team template if you have one.
• Email sequences and templates in your CRM or outbound tool. These are the ones that outlive people.
• Social bios — LinkedIn, X, GitHub profile, personal site.
• Website CTAs — “book a demo” buttons, contact pages, embedded widgets.
• Docs and wikis — onboarding pages, support macros, internal “how to reach X” notes.
• Calendar invite descriptions for recurring meetings that say “reschedule here.”
• QR codes on printed material. These cannot be updated. If any exist, keep the old link alive far longer, or point the QR at a redirect you control.
• Other people's systems — a partner's referral page, a customer's vendor record, a directory listing. You'll need to ask.

The general fix for the uncontrollable cases is to stop publishing vendor URLs at all. Put a redirect on a path you own — yourdomain.com/meet — and point it at whichever scheduler you use. Then the next migration is one DNS-level change instead of an archaeology project. This is worth doing duringthis migration, even though it's extra work, because it's the only version of this that you never have to repeat.

What to rebuild, in order

1. Availability, in your own timezone

Do this first, because every event type inherits from it. Set your working hours in your timezone, not the one the browser guessed, and confirm the timezone label explicitly. This is the single most common source of post-migration weirdness — see our write-up on timezone handling for why.

2. Event types, one at a time

Open the old tool and the new one side by side. For each event type copy across: duration, slot interval, buffers before and after, minimum notice, how far ahead people can book, the description, and any custom questions. Duration and buffers are the ones people get wrong, because the old tool's defaults were invisible.

3. Team links and hosts

If you have a shared team link, rebuild it and re-add every host — and then verify each one has connected their calendar. A host who hasn't connected a calendar can't be conflict-checked, so in Neos Meet they simply contribute no slots (we'd rather show fewer times than double-book someone). A team link that looks emptier than expected after a migration is nearly always this. Team scheduling covers the setup.

4. The booking page itself

Name, photo, the text invitees read. Small, and the only part of the migration your customers actually see.

Test before you publish (six checks)

1. Book yourself from a logged-out browser, end to end. Did the confirmation arrive? Did the calendar event appear with a working meeting link?
2. Book from a different timezone — change your machine's clock or ask a colleague abroad. Do the times match on both sides?
3. Cancel that booking from the invitee's email. Did both parties get told?
4. Reschedule another one. Did the calendar event move rather than duplicate?
5. Book a time you know is blocked in your calendar. It should not have been offered at all.
6. For a team link: book it twice and confirm two different hosts were assigned.

Do these before you change your email signature, not after. Every one of them takes under a minute and each has caught a real misconfiguration for someone.

What about the meetings already on the books?

They stay in the old tool, and that is fine. The calendar invites already exist on everyone's calendars; they will fire regardless of what happens to your scheduler subscription — with one caveat worth knowing: the old tool's reschedule and cancellinks stop working when the account lapses. So if you have bookings scheduled beyond your old tool's expiry date, either keep the account alive until they pass, or email those people a note with your new link. There are usually fewer than five of them.

A realistic timeline

For one person with a couple of event types: about fifteen minutes of setup, twenty minutes of link inventory, and then a two-to-four week passive drain during which you do nothing. For a team of 3–10, add a few minutes per host — each person connects their own calendar and confirms their own hours; there's no admin provisioning step to schedule around.

Frequently asked