Migrate from Acuity Scheduling to Easy!Appointments: what the move involves
A practice owner or operations lead who wants bookings on their own servers and an end to a recurring subscription should expect the move to be a rebuild, not an export. The work comes down to re-creating appointment types as services, calendars as providers, and the public booking link, plus a deliberate decision about intake forms and payment collection. Effort depends mostly on those last two, because Easy!Appointments covers online booking and scheduling core, while forms, deposits and reminders need either a manual process or custom development. In most practices the business owner or office manager does the configuration: services, durations, provider working hours and breaks. A developer or an implementation partner is usually needed for the server side: a PHP 8.2 or later host, a MySQL database, Apache or Nginx, and the configuration file and install steps described in the project's documentation. Easy!Appointments is free under GPL v3.0 with no per-calendar fee. Its author sells Premium Services covering installation, upgrades, migration, support and customization, so you can buy the migration help without buying the software.
Before you start, confirm with your provider what you can export from Acuity: client records, upcoming appointments and any intake responses, and in what format. Decide which of those you must carry over and which you will close out, since a future appointment left only in Acuity is a booking nobody sees. Ask the implementer to quote separately for data import, payment integration and any intake form replacement, because those line items drive the cost up or down. Plan a short period where both systems run, switch the booking link on your website only after a test booking reaches the right provider calendar, and confirm the new Google Calendar sync works for each provider before you cancel the Acuity plan.
Which Acuity capabilities map to Easy!Appointments, and which need rework
This table compares the main Acuity capabilities a client-booking business relies on with what Easy!Appointments provides out of the box. Read each row as clean (a direct equivalent exists), needs rework (possible, but configuration or custom development is required) or gap (not covered by the supplied product facts). Confirm intake form depth, package support and reminder options against the current release before you commit.
| Acuity capability | Easy!Appointments equivalent | Status |
|---|---|---|
| Appointment types | Services, each with duration, price fields and assigned providers | Clean: re-create each type as a service |
| Calendars and staff | Providers with their own working hours and services | Clean: re-create each calendar as a provider |
| Online booking page | Customer-facing online booking, embeddable on your website | Clean: confirm embed and branding options on your site |
| Google Calendar sync | Synchronization with Google Calendar is listed in the project's documentation | Clean: test two-way sync with each provider account |
| Client records and history | Customer records are stored in your own database | Needs rework: import and deduplicate records from an Acuity export |
| Upcoming appointments | Existing bookings must be entered or imported into the new schedule | Needs rework: plan a cutover date and freeze new bookings in Acuity |
| Intake forms | Not presented as a full form builder; field depth must be confirmed | Gap: plan custom fields or a separate forms tool, and confirm with the current release |
| Payment collection | Payments are not included; the author's site lists them as a custom development option | Needs rework: budget custom work or a payment integration |
| SMS reminders | SMS is listed as a custom development option, not a core feature | Needs rework: custom integration with an SMS provider |
| Packages and gift certificates | Not described in the supplied product facts | Gap: confirm with the maintainers; plan a workaround if absent |
What data moves, and which integrations you rebuild
Client records, upcoming appointments and availability can be carried across, but historical intake answers, payment records and anything wired through Acuity's add-ons need a different path. The cards below separate what you export, what you recreate and what needs custom development in Easy!Appointments.
Client records and contact details
Client profiles are the first thing to export from Acuity, usually as a customer list containing names, emails and phone numbers. Check the export in Acuity's own help documentation for the fields it actually includes, then map those columns to Easy!Appointments customer fields before importing. Confirm the import path in the current Easy!Appointments release, since field handling varies by version. Test with a few records before moving the full list.
Upcoming appointments and provider availability
Re-create each Acuity calendar as an Easy!Appointments provider with its working hours, breaks and days off. Upcoming bookings are the riskiest item to move by hand, so list them from Acuity's schedule view and enter them in Easy!Appointments only after the new booking page is live. Keep the two systems from accepting bookings for the same slot during the cutover window.
Google Calendar connection
Easy!Appointments synchronizes with Google Calendar, so each provider's availability and bookings can be checked against a personal calendar. Reconnect each provider account individually and confirm that events land on the correct calendar. Remove the Acuity Google connection once the new one is verified, or both systems may block the same time. Confirm the current sync behavior with the Easy!Appointments release you install.
Historical intake answers and payment records
Past intake form responses and payment history usually stay in Acuity or go to a separate archive, not into Easy!Appointments. Decide with your compliance lead how long each record must remain accessible and where it will live. Export what Acuity offers in its documentation, store it under your own access controls, and document the retention rule you chose.
Intake forms, payments and SMS reminders
Easy!Appointments does not ship intake forms, payment collection or SMS reminders as standard features. Its website says custom development can add SMS, payments, reports, reminders and third-party integrations, so each of these is a separate scoped build. Price each one from a written scope, and decide whether the payment processor and SMS provider contracts are yours to sign before work begins.
Website links and third-party embeds
Every page that links to or embeds the Acuity booking calendar must point to the new Easy!Appointments booking URL. List the pages, the embed snippets and any email templates or zaps that reference Acuity. Keep the Acuity link working with a redirect or a notice until the old links are updated, and test each booking path on mobile devices.
The migration sequence from inventory to decommission
This sequence moves a client-booking business from Acuity to Easy!Appointments without losing upcoming appointments or breaking the booking link. Each step produces a written artifact, so the cutover and the final shutdown rest on checks you can point to.
Inventory services, providers and open bookings
Export or list every Acuity appointment type, calendar, intake form, reminder and payment setting, then record which staff member owns each calendar. Pull the list of upcoming appointments and note which ones are paid, recurring or tied to packages. The output is a service mapping sheet that pairs each Acuity appointment type with a planned Easy!Appointments service and provider, plus a list of features you will rebuild or drop. Confirm the export formats Acuity offers for your plan before you start, since the available exports depend on your account.
Build and test a pilot with one provider
Install Easy!Appointments on your own PHP 8.2 or later host with MySQL, following the install steps in the project documentation. Create one provider, link the services that provider offers, set working hours and breaks, and enter the intake questions as notes or custom fields you have confirmed the install supports. Book test appointments from an outside browser and from a phone, then check the confirmation emails and calendar sync. The output is a tested pilot calendar with a short written list of defects and their fixes.
Confirm the pilot against real booking scenarios
Run the pilot with a few trusted clients who agree to test, covering rescheduling, cancellation, a no-show and a booking made near the end of the working day. Check that time zones display correctly for both the provider and the client and that the provider sees the same appointments in the calendar they already use. Record each result against the mapping sheet. The output is a signed-off pilot record that states which features work as planned and which need custom development or a manual workaround.
Load the client records and run both systems in parallel
Import client records and upcoming appointments that you have validated against Acuity, then keep Acuity live for new bookings while Easy!Appointments shows availability for the migrated providers. Compare the two calendars each day and resolve any conflict in favor of the appointment already confirmed with the client. Keep a log of double-bookings and missed reminders. The output is a reconciliation log that shows the two systems agree on every upcoming appointment before you move on.
Replace payments and reminders before cutover
Decide how deposits, card payments and SMS reminders will work once Acuity stops collecting them. Easy!Appointments lists payments and SMS among features that custom development can add, so agree the scope, build and test those integrations in writing with your provider before cutover. If you accept a manual process in the interim, document who collects payment and how reminders are sent. The output is a signed-off payments and reminders plan that a staff member can run without Acuity.
Switch the website booking link and sign off cutover
Replace every Acuity embed, booking button and direct link on the website and in email signatures with the Easy!Appointments booking address. Test each page from a clean browser session and confirm that old Acuity links redirect or display a clear message. Walk the cutover checklist with the business owner and the staff who take bookings. The output is a signed-off cutover checklist that records the date of the switch and the person who approved it.
Confirm no open appointments and decommission Acuity
Once new bookings have run through Easy!Appointments for a period you set with your team, confirm in Acuity that no future appointments remain and that all final invoices, payment records and client exports are saved to your own storage. Export the data you need to keep, then cancel the Acuity subscription and remove embeds from the website. The output is a decommission record that lists the final export, the date of cancellation and the owner of the retained data.
How to run both systems in parallel and cut over safely
The main risk during the overlap is a double booking, where a client books the same provider slot in Acuity and in Easy!Appointments. Avoid it by assigning each provider to one system for new bookings from a fixed date. Until then, keep Acuity as the only place where that provider accepts bookings, and mirror its unavailable time into Easy!Appointments as blocked periods on the provider's calendar. Once the provider is switched, do the reverse: block the same time in Acuity so clients cannot book there. Work through providers one at a time and record the switch date for each in a shared cutover sheet, so the team knows which system owns which calendar on any given day.
Acuity appointments that are already booked must be honored in Acuity until they pass. Do not cancel or move them to Easy!Appointments unless the client agrees, because that creates a second confirmation and a second reminder. Pick a cutover date after which the old Acuity booking link redirects to the Easy!Appointments booking page, and keep the redirect in place for as long as clients may still hold links or bookmarks. Confirm with your Easy!Appointments administrator that reminder emails are sent from the new system only after the cutover, and that clients receive no reminders from both.
Clients with saved reminders, calendar invitations or intake forms need a short, dated message before the switch. Explain which system will hold their next appointment, what to do if they booked in Acuity, and where to complete intake forms after the change. Intake questions are not a built-in feature in Easy!Appointments, so confirm with your developer how any replacement form will be delivered and whether completed answers will be stored in your own database. Keep the old Acuity intake responses available for the retention period your practice requires, and tell clients where they can request those records.
What drives the cost and duration of this migration
This table lists the main drivers of migration cost and effort, who is paid for each piece, whether it is one-time or recurring, and what to request in a written quote. Use it to compare scope items side by side and to see which ones your own team can absorb.
| Driver | Why it changes cost or effort | What to ask for in a quote |
|---|---|---|
| Number of services and providers | Each Acuity appointment type must be rebuilt as a service and each bookable calendar as a provider, so counts drive configuration hours. | Itemized count of services, providers and availability rules, with a fixed scope for their setup. |
| Volume of upcoming appointments | Future bookings must be carried over and checked against new provider calendars, which adds data handling and verification work. | Whether carrying over upcoming appointments is included, and how the cutover date and double-booking checks are handled. |
| Client records and history | Client profiles and notes need mapping and cleaning before import, and cleanup work is often the largest hidden item. | Who exports and maps the data, what cleanup is included, and how privacy-sensitive fields are handled. |
| Intake form complexity | Acuity intake questions have no direct equivalent in Easy!Appointments, so each form must be rebuilt through custom work or replaced by another tool. | Number of forms and questions, field types, and whether forms are built by the vendor, the client or a third party. |
| Payment collection changes | Easy!Appointments does not include payments out of the box, so a payment provider integration is custom development, with its own setup and testing. | Named payment provider, integration scope, testing with live and test modes, and who holds provider credentials. |
| SMS and reminder requirements | SMS and reminders are not native features, so each channel is a separate integration with its own provider account and message rules. | Channels required, message templates, sending provider, and whether provider fees are passed through to the client. |
| Hosting and PHP setup | Easy!Appointments needs PHP 8.2 or later, MySQL and a web server, so hosting setup, TLS and backups are work items before any data moves. | Who provisions hosting, who pays hosting, and who owns the backup and patching schedule after go-live. |
| In-house developer capacity | Teams with PHP and MySQL skills can do more configuration themselves, which shifts cost from external fees to internal time. | Which tasks stay in-house, which are vendor-delivered, and the handover documents for each. |
| Website booking link switch | Replacing Acuity links and embeds on the website, plus redirects for old booking URLs, is small but must be planned to avoid lost bookings. | Confirmation that link and embed changes, redirects and a post-switch check are in the written scope. |
How the migration differs by practice size and starting point
A solo practitioner with a few services, one calendar and a booking link on the website usually has the smallest migration. The work is mostly re-creating a short list of appointment types as services and the single calendar as one provider, then checking availability rules against the real working week. Because there are few records, the owner often does the work personally, which keeps decisions quick but also means nobody checks the result independently.
- Service list: Re-create each appointment type with its duration, buffer and price description, and drop types that are no longer offered.
- Provider record: Add the one calendar as a provider and confirm working hours, breaks and time zone match the Acuity settings.
- Client history: Decide whether past clients are exported or whether only upcoming appointments are carried over, since a small client list is quick to re-enter by hand.
- Booking link: Plan the switch date so the old Acuity link keeps working until the new page is tested.
- Hosting: Confirm who will run PHP 8.2 or later and MySQL, or whether a provider will install and host the instance.
Check that a test booking reaches your calendar and that cancellation and reschedule notices behave as you expect before you change the website link.
A clinic or salon with several providers, rooms and shared resources has more moving parts. Each practitioner becomes a provider with its own hours, the services they perform must be mapped to the right providers, and overlapping schedules need checking. Ownership usually splits between an office manager who knows the bookings, an IT or web contact who handles hosting and the website, and sometimes a staff member who knows the clinical or service rules. Decisions about who may book which service and how cancellations are handled should come before any data is moved.
- Provider mapping: Build a matrix of providers against services so that each service only appears where it is actually delivered.
- Working hours: Recheck each provider's schedule, holidays and break times, because mistakes here cause double bookings.
- Client records: Decide which client fields are needed, and avoid importing health or sensitive intake data into fields that were not designed for it.
- Staff access: Define which staff accounts can see which calendars before go-live.
- Parallel running: Keep Acuity active for existing bookings until the upcoming appointments have moved, then switch the link.
Confirm with each provider that their calendar reflects their real availability in the new system before the website changes.
A business that already uses packages, intake forms, payment collection and reminders relies on Acuity features that Easy!Appointments does not include out of the box. The migration then covers a replacement decision for each feature, not only the booking calendar. Easy!Appointments can be extended through custom development for SMS, payments, reports, reminders and third-party integrations, so the scope depends on which of these your current workflow truly needs. Ownership is usually shared between the business owner, a developer or integrator, and whoever handles payment and privacy obligations.
- Feature inventory: List every Acuity feature in daily use, including packages, gift certificates, intake questionnaires and reminder messages, before deciding anything.
- Replacement path: For each feature, choose between a custom build, a separate tool, or dropping it, and record the owner of that choice.
- Payments: Confirm which payment processor will be connected and who holds the merchant account, since this affects compliance responsibilities.
- Intake data: Decide where questionnaire answers are stored and who can read them, especially if they contain health or personal information.
- Existing packages: Agree how prepaid packages and balances held by clients will be honored during the cut-over.
Ask any integrator for a written list of which features are included, which are custom work, and which will be dropped, so the scope is agreed before build starts.
What usually goes wrong and how to prevent it
Most failed Acuity to Easy!Appointments cutovers come from a short list of gaps: two systems taking bookings at once, appointments that never moved, and settings that quietly differ. Each card below names one failure, why it matters for this migration, and the check that catches it before clients do.
Double bookings during the overlap
While Acuity and Easy!Appointments both accept bookings, the same provider can be offered the same slot twice. Pick a cutover date, then close bookings in Acuity for each calendar as you open it in Easy!Appointments. Compare every provider's schedule in both systems for the overlap week and confirm that no slot appears in both before you remove the old booking link.
Lost upcoming appointments
Existing future appointments are not always carried over with the client records, so a client may hold a confirmed Acuity slot that does not exist in Easy!Appointments. Export the upcoming appointment list from Acuity, re-enter or import each one into the matching provider calendar, and check the count and dates against the export line by line. Keep the Acuity account readable for the remaining appointment window.
Broken website booking links
Embedded Acuity widgets and direct booking URLs on the website, in emails and in social profiles keep sending clients to the old system after launch. Inventory every place the link appears, replace each one with the Easy!Appointments booking page, and test each link from a logged-out browser. Set a redirect or a holding message on the old address for as long as clients may still use it.
Unmigrated intake forms
Acuity intake questions, consent wording and file uploads do not map one to one onto Easy!Appointments, which has no native intake form builder. Export your current questions, decide which are still required, and rebuild them through custom development or a separate form tool. Confirm that signed consent and health or personal information are stored where your policy says they must be.
Payment and deposit gaps
Easy!Appointments does not collect payments on its own, so deposits, prepaid packages and refunds can stop working on the day you switch. Decide which payment flows you need, confirm the payment provider and its integration through custom development, and run a test charge and refund before go-live. Reconcile open balances from Acuity so no client is charged twice or missed.
Reminder messages that stop
Acuity sends email and SMS reminders by default, and those messages end the day the account closes. Easy!Appointments reminders and any SMS step must be configured or built separately, so a client may receive no reminder for their first appointment. Send a test reminder for each appointment type, check the sender address and message template, and confirm delivery with a real client before relying on it.
Time zone and daylight saving errors
A booking can display at the wrong hour when the server, the database and the provider calendars use different time zones. Set the server time zone, the application time zone and each provider's working hours explicitly, then book test appointments across a daylight saving change. Verify that a client in another time zone sees the time the provider expects.
Weak PHP and MySQL hosting
Easy!Appointments needs PHP 8.2 or later, a MySQL database and Apache or Nginx, and an outage or unpatched stack puts every booking at risk. Ask your host or internal team to confirm the PHP and MySQL versions, enforce HTTPS, restrict database access, and schedule tested backups. Confirm the exact version requirements against the project repository before you provision the server.
Questions buyers ask before moving from Acuity
What does it cost to move from Acuity to Easy!Appointments?
The software itself carries no license fee, so the cost is the work to install, configure and connect it, plus the hosting you pay for. Easy!Appointments is free with no recurring fees or booking commissions, according to its website. Costs fall into four parts: hosting a PHP and MySQL server, installation and configuration, migrating existing data, and custom work for features Acuity bundles, such as payments, SMS reminders and intake forms. The first two are mostly one-time. Hosting, backups, updates and support recur. Ask any implementation partner for a quote built from a written scope that lists each of these parts separately.
How long does a move from Acuity take?
The timeline depends on how many appointment types, providers and calendar connections you have, how much history you need to carry over, and how many features must be rebuilt. A single practitioner with a few appointment types and no payments to reconnect will move faster than a clinic with several providers, intake questionnaires and deposit rules. Your own availability to review data and test bookings also sets the pace. Ask for the timeline to be tied to the written scope and milestones rather than estimated in the abstract.
What must my practice supply before the migration starts?
Plan to supply the decisions and access that only your practice can provide:
- A list of appointment types, durations, prices and buffer times to re-create as services
- A list of providers and the working hours each one keeps
- Access to your web host or DNS so the booking link can be switched
- Your chosen payment processor account and any SMS provider credentials
- A named person who signs off on test bookings and the cutover date
Missing decisions here are the most common source of delay, so settle them before technical work begins.
Can a practice migrate from Acuity without outside help?
A technically confident owner can install Easy!Appointments by creating a database, copying the files, editing the configuration file and opening the install URL, as described in its documentation. Setup is the easy part. Carrying over client records, rebuilding intake and payment flows, testing the booking page and keeping backups and updates running are where errors appear. Doing it alone is realistic for a small practice with simple services and no payments. For regulated or multi-provider setups, consider a fixed-scope engagement, or the paid installation, migration and customization services the Easy!Appointments author offers.
Which Acuity data can I export and bring across?
Export what Acuity allows you to download, then confirm each file type with Acuity's own export options before you plan around it. In most cases the portable items are client contact details, appointment history and upcoming bookings. Import them into Easy!Appointments only after you map each field to a customer, service or provider record. Payment card data is not something you should expect to copy between systems. Check how each exported file handles dates and time zones, and test a few records before importing the full set.
What happens to payments and SMS reminders after the move?
Acuity's built-in payment collection and SMS reminders do not carry over automatically. Easy!Appointments does not include them in the core product, and its website says custom development can add SMS, payments, reminders and third-party integrations. Plan a separate payment processor account and an SMS provider, then budget for the integration work. Until those are live, decide whether clients pay in person or by invoice, and tell clients about any change before cutover. Confirm the processor's terms and your privacy duties for reminder messages.
What security and operations work do I take on after go-live?
Once Easy!Appointments runs on your own server, you own its security and availability. That includes keeping PHP and MySQL supported, applying Easy!Appointments updates, restricting access to the admin area, enforcing HTTPS on the booking page, and running tested backups of the database and files. Client intake details are personal data, so confirm who can see them and how long they are kept. Acuity handles much of this for you, so ask a provider to document these tasks in a runbook and to name who responds when the booking page goes down.
How DeployOpen scopes and runs the migration
DeployOpen plans and implements the move from Acuity Scheduling to a self-hosted Easy!Appointments instance inside your own infrastructure. Engagements are fixed-scope, so the services, providers, client records, intake replacement and website changes are agreed in writing before any work starts.
How we scope
- Inventory every Acuity appointment type, calendar, intake form and payment step that the business relies on today
- Map each appointment type to an Easy!Appointments service and each calendar to a provider, with agreed naming
- Define how client records and upcoming bookings will be carried over, and which history stays in Acuity
- Agree in writing how intake questions and payment collection will be replaced, including any custom development
How we build
- Install Easy!Appointments on PHP 8.2 or later with MySQL and Apache or Nginx in your chosen hosting environment
- Configure services, providers, working hours and Google Calendar synchronization to match the scoped schedule
- Run test bookings from the public booking link across each service and provider before cutover
- Document the configuration, database backup routine and any custom changes so your team can maintain them
How we hand over
- Deliver the migrated records, configuration notes and a short runbook for staff who manage bookings
- Walk through the booking link switch on your website, including a rollback step if a booking fails
- Confirm with your team which Acuity subscription actions and data exports are their responsibility
- Provide a handover checklist covering access, backups, admin accounts and open items
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover Easy!Appointments version upgrades, backup checks and changes to services or providers
- Ask any provider to confirm how security updates and hosting maintenance will be handled in the quote
- Plan periodic review of the booking flow, since client intake needs can change as the business grows
