Switching to Aced
What moves, what does not, and who does the moving
A migration page is only useful if it names the losses. Here is what comes across cleanly, what usually does not, and how each gap gets a decision attached before go-live rather than after.
Data
What comes across
| Data | How it moves | What to watch |
|---|---|---|
| Customers & members | CSV import with presets for common source formats | Duplicates across your old tee sheet and POS. Detection and merging happen after import, not before. |
| Item catalogue | CSV import with categories and costs | Option groups and modifiers usually need restructuring — it is the largest single piece of catalogue work. |
| Gift cards & store credit | CSV import of outstanding balances | Reconcile the balance list on a fixed date and stop issuing on the old system from then. |
| Rate structure | Rebuilt as rate classes and green-fee rules | The rules that only exist in a staff member's head are the ones that get missed. Write them down. |
| Memberships | Imported with their installment schedules where the source exports them | Payment methods do not transfer between processors; cards on file are re-collected. |
| Website & domain | Rebuilt in the builder; domain re-pointed | URL mapping and redirects are planned before the switch so search positions are not thrown away. |
The honest half
What usually does not move
Every one of these is survivable if it is a decision. None of them is survivable as a surprise.
| Does not move | Why | What we do instead |
|---|---|---|
| Full transaction history | Most systems either will not export it or export it in a shape that cannot be reconstructed faithfully. | Keep a read-only export from the old system for the record, and start clean history in Aced from a dated cutover. |
| Saved card details | Cards on file live with the processor. They do not transfer between processors. | Members and house accounts re-add a card once, usually during the first visit after go-live. |
| Report definitions | A “monthly revenue” figure means slightly different things in different systems. | Reconcile a known month during validation so you can see exactly where and why the two differ. |
| Custom fields with no equivalent | Some systems carry bespoke fields that have no home in a different data model. | Identified in discovery, then either mapped to something real or explicitly dropped in the scope. |
Based on Aced’s import tooling and current migration practice, August 2026.
Sequence
How a switch is actually scheduled
- 1
Fix the cutover date
Chosen against your season and your current contract's notice period, not against our calendar.
- 2
Freeze and export
A clean export from the old system on a fixed date, with issuing of new gift cards and credits stopped there.
- 3
Import and reconcile
Data loads into Aced and is checked against the source before staff see it.
- 4
Validate then switch
Staff work the sandbox until reports reconcile; the old system stays live until the day you go.
Two tee sheets cannot both be authoritative
Switching
The scariest thing a course does all year
Changing the system that takes the money deserves a written scope, a mapped export and a redirect plan. What does not survive the move is identified in discovery, not discovered in month two.
Migration questions
What data can I bring across?
Customers and members, the item catalogue, outstanding gift-card and store-credit balances, and your rate structure. CSV import handles these with presets for common source formats, and the mapping is agreed before anything is loaded.
What usually does not move?
Detailed transaction history from systems that will not export it, report definitions that differ from ours, and anything held in a vendor's proprietary format with no export path. This is identified in discovery and written into the scope so it is a known decision rather than a month-two discovery.
Will my website's search rankings survive?
That depends on the redirect plan more than on the platform. Moving a site is about domains, URL mapping and redirects, and that work is planned and written down before anything is pointed at a new host.
Can I run both systems in parallel?
Not for live bookings — two authoritative tee sheets is how a Saturday gets double-booked. What runs in parallel is validation: staff work an Aced sandbox with your real data while the old system stays live, until the reports reconcile.
What about my current contract?
Bring the notice period and renewal date to discovery. A go-live date that lands two weeks after an auto-renewal is an expensive scheduling mistake, and it is entirely avoidable if it is on the table early.
Send us an export and we will tell you what survives
The most useful thing you can bring to a first conversation is a customer export and an item list. We will map them against Aced and be specific about what needs a decision.