What data actually carries over?

Items, prices, barcodes, categories, and modifiers import from a spreadsheet or your old POS export. Historical transaction data is the honest exception — most incumbent systems export it poorly if at all, and reconstructing it is rarely worth what it costs. Most businesses keep the old system read-only for a period instead, which is cheaper and works.

We're mid-contract with our current vendor. Should we wait?

Work out the remaining cost and weigh it against what you are losing monthly by staying. Sometimes running both for two months is the cheaper answer; sometimes waiting out the term genuinely is. We will do that arithmetic with you honestly, including the version where the answer is to call us back in the spring.

How long until staff are comfortable?

Ringing a sale is usually minutes — the flow is deliberately close to what people already expect. Comfort with the parts used less often, like returns, voids, and end-of-day, takes a few shifts. Switching during a quiet week is what makes that learning free rather than stressful.

What if we start and it isn't right for us?

You will know within the first day rather than after a three-week implementation, which is the practical benefit of short onboarding. Keep your old system available until you are confident — we would suggest it regardless — and if it is not the right fit, you have lost an afternoon instead of a quarter.

Can you do the migration for us?

We do it with you on the onboarding call. That is deliberate rather than a limitation: the person who knows your catalog is the person who should confirm how it maps, and having you present for the mapping is what prevents the class of error that surfaces three weeks later as a wrong price.

Pacific POS · Switching

Changing POS without closing

Your catalog imports from a spreadsheet or your old system's export, and the changeover happens between services. Here's exactly what moves, what doesn't, and how to sequence it.

Run both systems for one serviceCut over while you are shutExport your history first

Staff member configuring a touchscreen terminal on a shop counter

The sequence

4 steps, one closed evening

Migration happens inside the same onboarding — live in about ten minutes.

Export what you have
Pull your menu or product list out of your current system. A CSV or spreadsheet is enough — most POS platforms export one.
We map the columns
Names, prices, categories, modifiers and customer lists get mapped to Pacific POS on the onboarding call. You watch it happen.
Run both for a shift
Keep the old system live alongside ours for one service. Compare the totals at close before you commit to the switch.
Cut over between services
The changeover happens while you're closed. Nobody stands at a broken register in front of a queue.

Comes across

What we import

Menu and product catalog, with categories
Prices and modifiers
Customer lists
Tax rates and configuration

Doesn't come across

What to handle yourself

Historical transactions

Sales history stays in your old system. Export your reports before you cancel — most platforms cut access when the subscription ends.

Loyalty point balances

Point balances rarely export in a usable form. If you run a loyalty program, tell us early and we'll plan how to honour existing balances.

Your old contract

We can't end it for you. Check the notice period before you switch — overlapping a month is common and usually cheaper than breaking a term early.

Export your reports before you cancel

This is the mistake that costs people most: most POS platforms cut off access the day the subscription ends, taking years of sales history with them. Pull your reports first, whoever you end up switching to.

Your situation

What are you switching from?

The migration is easier or harder depending on where your data lives today, not on whose logo is on the terminal. Find yourself below.

Switching from a legacy on-premise POS

There is a server in the back office, and support means a call-out

The hard part is not the software — it is that your data is sitting on a machine in the back office and the person who set it up has moved on. Here is how that migration actually goes.

Read this one

Switching from a card terminal and a spreadsheet

Payments work. Everything around them is manual

You take card payments fine — the terminal does that. What you do not have is a system that knows what was sold, so every question about the business is answered by retyping receipts.

Read this one

Buying your first POS

A till, a notebook, and everything in somebody's head

Almost nobody buys their first POS from a standing start any more, which makes this the least written-about migration and often the most nervous one. There is no data to move — the risk is entirely in the changeover.

Read this one

Consolidating locations onto one system

Two sites, two systems, and figures that never quite agree

Each location works. The problem appears when you try to compare them — different products named differently, different reporting periods, and a head-office view that is really a spreadsheet somebody rebuilds every month.

Read this one

Timing

When to switch, and when not to

Point-of-sale terminal on a counter during service

The best time to switch is a slow week you can see coming. Not a closure — you do not need one — but a stretch where the trading volume is low enough that a staff member spending twenty minutes learning a new screen costs you nothing. Every business has these, and picking one deliberately removes most of the risk people associate with migration.

The worst time is the week before your busiest period of the year, and the number of businesses that attempt it anyway is remarkable. The logic is understandable — get the new system in before the rush so it is ready — and it is backwards. Go into your peak on the system your staff know, and switch immediately after it while the season's data is fresh and worth importing.

There is also a case for not switching at all, and we would rather make it here than after you have signed something. If your current system works, your staff are fluent in it, and your complaint is a feature you would use twice a year, the disruption is not worth it. Switching costs are real even when they are small, and a POS decision that saves nothing operationally has cost you a week of attention.

The genuine reasons to move are structural: stock counts still done on a clipboard, reports you have to export to be useful, hardware you are locked into replacing, or a system that cannot represent something your business now does. Those compound every month you wait, which is the difference between a switch worth planning and one worth skipping.

FAQ

Switching, answered

Data, timing, contracts, and the parts that genuinely don't carry over.

Merilsoft team answering a customer's question

Not seeing your question?

Tell us how you run today and we'll answer specifically.

Book a Demo See all questions

No. The usual pattern is to import your catalog and configure during a quiet period while your existing system keeps trading, then cut over between shifts. There is no installation appointment and nothing to provision, which is what removes the scheduled-downtime problem entirely rather than shortening it.