How to move your play area's data onto new software

Most of the fear in a migration comes from a single worry: that something will silently go missing and nobody will notice until a parent turns up with a pass that no longer exists. The method below is built to remove exactly that worry, by putting a reading step in front of every writing step and by tying every figure to something you counted yourself. It applies whichever system you are moving to; where a detail is specific to PlayAreaOS, the switching page covers it.

1. Export what you hold today, as CSV.
2. Check the file, and read what the check says before a row is written.
3. Fix the source file, and check again.
4. Import.
5. Set the opening balances.
6. Cut over on one date, and keep the old system readable.

Step 1: Export what you hold

Start where the data already lives, and take more than you think you need — a spare column costs nothing, and a column you failed to export is a phone call to a system you have stopped paying for. Two files carry most of the value:

• The product list. Every session length, every party package and add-on, the cafe and retail lines, each with its price, its tax treatment and whatever code your team recognises it by.
• The customer list. Parent name, mobile number, email, the children with their dates of birth where you hold them, and each family's marketing preference, which travels with them and must not be quietly reset by the move.

Then take everything else as a read-only record rather than an import: the last twelve months of sales by day, the outstanding passes with visits remaining, the party bookings with dates and deposits, supplier balances, and your stock list with quantities and costs. Some of it will be imported, some of it becomes an opening balance, and the rest exists so you can answer a question in March about a Saturday in January.

CSV is the right format for all of it: plain, readable in any spreadsheet, and readable in ten years. Keep the untouched original of every export in a folder nobody edits, and work only on copies. When a check report says something surprising, the original is what tells you whether the surprise came from the old system or from your own tidying.

Step 2: Check before anything is written

This is the step that takes the fear out of the rest. A good import reads your file, reports what it would create and what looks wrong, and writes nothing until you say so. Ask any candidate system for that check before you commit to it; a system that writes first and reports afterwards is asking you to trust a file you have not read.

What a useful check report tells you, and what to do about each:

• Row counts. How many products and customers it found, against how many rows you exported. A gap of two usually means blank rows at the bottom of the file; a gap of two hundred means a column shifted.
• Duplicates. The same parent under two spellings, or one mobile number on three records. Merge them in the source file, where you can see both, rather than after the import.
• Missing values. A product with no price, a customer with no contact of any kind. Decide whether each one is a real record worth fixing or a leftover worth deleting.
• Unreadable values. Dates in a format the file does not declare, prices with a currency symbol inside the number, phone numbers stripped of a leading zero by a spreadsheet. These are the classic silent corruptions, and they are all visible in a check report and invisible after an import.
• Columns it did not recognise. Either a heading to rename, or data that belongs somewhere else in the new system.

Step 3: Fix the source, and check again

Read the report as a preview rather than a verdict. It exists so that problems are caught while they are still cheap, and the cheapest place to fix nearly all of them is the source file itself: correct it in the spreadsheet, save it, and run the check again. Nothing has been written, so there is nothing to unpick — you are simply making the file into one you are happy to commit.

Two habits make this loop fast. Fix in batches rather than one row at a time, since the same fault usually affects a whole column. And write down what you changed and why, in a note beside the file, because in three weeks somebody will ask why the old system says 412 customers and the new one says 407, and "we removed five duplicates on the 14th" is a much better answer than a shrug.

Step 4: Import

When the report is clean, run the import. The property worth insisting on here is that running the same file twice does not double your data: a well-built import recognises rows it has already brought in, so a correction is a re-run rather than a restart. Ask about that explicitly, because it is the difference between a small mistake and an evening spent deleting duplicate customers by hand.

Import in a sensible order, because the later files lean on the earlier ones: products first, then customers, then anything that refers to both. Check a handful of records by hand afterwards — a family you know, a package you sell every week, the most expensive line on the price list — because a spot check by a human catches the class of error no report is looking for.

Step 5: Set the opening balances

Lists are only half a migration. The other half is where the business stands on the morning you switch, and that is what opening balances record. Get them wrong and every report for a year quietly disagrees with reality; get them right and day one starts from the truth.

Count each of these on the cutover date itself, not the week before:

Formula. Opening stock value = Σ (units counted on the shelf × unit cost).

Formula. Outstanding pass liability = Σ (unused visits on each live pass × the amount paid per visit). This is money you have taken and still owe in play; it belongs on your books as a liability rather than as revenue already earned.

Formula. Deposits held = Σ (deposits taken for party dates falling after the cutover).

Formula. Supplier balance = Σ (invoices received − payments made), per supplier, at the cutover date.

Formula. Cash position = counted float + takings counted but still awaiting the bank.

Payroll needs a starting line of its own: each employee's start date, their salary, the leave they have taken so far this year, and any advance or loan still being repaid. Those figures decide the first payslip and, in countries with a statutory end-of-service calculation, they decide a number you will not want to reconstruct in five years.

Alongside the balances, this is the moment to enter the things a new system arrives without: your prices, packages, add-ons, deposit rules, tax rate and currency. It is worth doing deliberately rather than copying the old list line for line — a migration is the one moment when reviewing every price costs you nothing extra.

Step 6: Cut over on one date

A switch goes wrong most quietly when it goes wrong humanly: for a few days some things are entered in the old system and some in the new, and the truth sits in neither. One date fixes that, and the date is a decision rather than a technical event.

• Pick a quiet day. The morning after a slow weekday beats the morning after a Saturday, because the counting is easier and a mistake is cheaper.
• Stop entering anything in the old system from that moment. Announce it to the whole team, in writing, with the date and the hour on it.
• Count and enter the opening balances before the first sale on the new system, while the counted figures are still true.
• Keep the old system readable for at least a full tax year: reports, receipts and party history, in an export you hold yourself rather than a login you might lose.
• Run the first week deliberately. Reconcile every shift close on the new system against a counted drawer, and read the day's reports each evening. A gap found on day two is a fixable typo; the same gap found in March is an audit.

A worked tie-out

A venue switches on a Tuesday morning. Before opening, the owner counts and writes down five lines in the venue's own currency:

1. Stock. 240 juice cartons at 1.20, 90 grip socks at 2.50, 60 party bags at 4.00 = 288 + 225 + 240 = 753.
2. Passes. 46 live passes with 173 unused visits between them; each visit was paid at 8.00 = 1,384 owed in play.
3. Deposits. 11 parties booked for dates after Tuesday, each with a 50 deposit = 550 held.
4. Suppliers. Two invoices received and unpaid, 620 and 310 = 930 owed.
5. Cash. A 500 float plus 1,240 of takings still awaiting the bank = 1,740 on hand.

Each figure is entered as an opening balance and then checked against the old system's own report for the same date. Where the two disagree, the counted figure wins for stock and cash — you are holding it — and the old system's figure wins for passes and deposits, because those are promises you made to families and the record of them is the record that matters. Any difference that survives gets written down with its explanation before the doors open, and never resolved by quietly changing a number afterwards.

Waivers: what carries, and what is signed again

Handle waivers as their own decision, because they behave differently from everything else in the export. A signature belongs to a particular wording at a particular moment, so carrying signature images between systems produces a record that looks reassuring and proves very little. The safer reading is that a migration is the natural moment for families to sign your current wording.

What does carry usefully is coverage: the date the previous waiver ran until. A returning family who signed six weeks ago is treated as covered until that date arrives, and signs your own wording on their next visit after it, so nobody is asked to re-sign twice in a fortnight and the door still moves quickly on a Saturday. The waiver management guide covers how that first-visit signing runs at the door, and digital waivers shows the QR version.

After go-live

Once the cutover date has passed, the work is habit rather than project. Reconcile the first week's shift closes daily and the second week's weekly. Compare the first full month against the same month in the old system's export — visits, takings, revenue per visitor — and expect small differences you can explain rather than none at all. Then check that your records are being backed up somewhere other than the machine you are reading them on, and that somebody has actually watched a restore work. The backups and migration page covers that side, and the KPI guide defines the measures worth comparing across the join.