POS migration checklist for retailers

A POS migration is the process of switching from an existing point-of-sale system to a new one. It can involve transferring product, stock and customer data, setting up tills, scanners and payment terminals, and making sure the new system works with the retailer's existing software. Store staff also need to be familiar with the new system before they start using it. Retailers can switch all stores at once or move in stages, depending on their store operations, systems and support capacity.

This POS migration checklist covers what UK retailers switching EPOS systems need to prepare and test before the first store goes live. It includes data migration, hardware, payments, integrations, staff training, cutover and plans for returning to the old system if something goes wrong. For each check, the checklist sets out what needs to be done, who is responsible and how completion should be verified. Retail teams can use it to decide whether they are ready to switch to the new system.

POS migration checklist

This EPOS migration checklist has seven gates, and each gate passes when its owner has accepted the evidence. Set your own thresholds, including sample sizes and acceptable differences, before testing starts.

Record each test with an ID, the store and register, the scenario, the expected and actual results, the owner, the status, an evidence reference and a retest date. Each test carries one of four statuses, which are open, passed, failed and not applicable, and a not applicable status needs a stated reason.

POS implementation plan for switching EPOS systems

A POS implementation plan is the working document for an EPOS implementation. It records what the migration covers, who owns each part and who decides whether the new system goes live. Agree it before any data moves, because testing and cutover both depend on it.

Scope

List the stores and registers in the POS migration, the sales channels connected to the till, the data to be moved, the workflows the new system must support and the integrations it must keep. Record what is excluded and which records stay in a searchable archive.

Ownership

Give each of these areas one named owner.

• Product and price data

• Tax and VAT settings

• Stock

• Customer, loyalty and gift card records

• Payments

• Finance reporting

• Staff access and permissions

Source of truth

For each data group, name the system that holds the authoritative version and record how changes made after the trial load reach the new system.

Authority and sign-off 

Name who accepts test results, who can delay the launch and who decides between fixing a fault in the live system and returning to the old one. Keep a signed scope, a system map, an owner list, a decision log and a list of known risks as evidence for this stage.

What data needs to move during a POS migration?

A POS data migration moves the information the new EPOS needs on its first day. That means products, prices, tax settings, stock in each store, staff logins and, where the stores use them, customer loyalty, gift card and order records. Older records can stay in a searchable archive.

Give each group of data one of three decisions.

• Move means the records are copied into the new system.

• Set up again means the rule is created afresh in the new system, which is common for promotions and staff permissions.

• Archive means the records stay available to search outside the new system.

How a POS data migration works

Start by migrating a small sample of data, followed by a full trial migration and a final transfer just before cutover. Keep record IDs consistent between the old and new systems, and map each field to its equivalent in the new system. Document any changes made to the data during migration.

Record any data that fails to transfer, along with the reason and the person responsible for resolving it. Once the final transfer is complete, compare record counts and key values across both systems to confirm that the data is accurate and complete. Keep these checks documented as evidence.

Before migration, confirm the required order of data transfer, the amount of historical data that can be retained and how gift card balances will be handled. These requirements depend on the new POS provider.

UK VAT checks if the EPOS is used for VAT accounting

HMRC's guidance for its officers on VAT retail schemes says an EPOS used for VAT accounting needs a product file that identifies the VAT treatment of each item. A second section of that guidance covers situations officers ask about when a retailer introduces or upgrades a system, including items that fail to scan, failed VAT rate look-ups, items that carry more than one VAT rate and discounts. These scenarios should form part of the POS migration tests, with the finance owner reviewing and approving the results.

Customer data and archiving

Under the ICO's data minimisation principle, retailers should only collect and retain personal data that is necessary for a defined purpose. They should also review the information they hold and delete records they no longer need.

Before migration, the data protection owner should identify which customer fields need to move to the new EPOS, who should have access to them and which records should be archived. The retailer's data protection team should also confirm the legal basis for processing the data and how long the records need to be retained.

How to test a new EPOS system?

To test a new EPOS system, start by checking that the migrated data and system settings are correct. Then test the hardware, payment methods and everyday store transactions, including sales, refunds and discounts. Next, check integrations with other systems, staff access permissions and end-of-day procedures. Finish by testing the cutover process and how the system handles failures. For each test, record the expected result, the actual result, the person responsible and the final sign-off.

POS testing checklist

The table below covers the main tests, the expected results and who is responsible for each one. You can add or adjust the tests based on how your stores operate.

Use the VAT row if the EPOS is used for VAT accounting. It follows the questions in HMRC's guidance on item scanning and VAT rate look-ups, and the finance owner approves the test cases.

Payment tests and PCI DSS

Use the payment provider's test process for payment tests. If a live card payment is needed, agree a controlled payment and refund with the payment provider and finance in advance. The PCI Security Standards Council says payment terminals are part of the cardholder data environment and are in scope for PCI DSS. PCI DSS leaves the choice of payment device open, although some payment brands require PTS-approved devices, so check the requirement with the bank or provider that processes the card payments.

Offline and network failure tests

The till and the card terminal each need a test for loss of internet connection. Ask your payment provider whether it supports offline payments, what limits apply and who carries the risk if a stored payment is later declined. Where offline payments are unavailable, test the store's fallback, such as taking cash only or pausing trading.

Agree sample sizes, response times and the number of faults to accept before testing starts. Have store staff run the scenarios themselves, so the test also shows whether training has worked.

Should stores migrate simultaneously or in stages?

The decision depends on how your stores operate and how similar their systems are. A phased retail POS rollout works well when stores have different formats, hardware or integrations, as you can identify and resolve issues before moving to the next group. Migrating all stores at once may be suitable when systems are standardised, connected platforms need to switch together and the recovery process has been tested.

AWS's cutover guidance, written for cloud migrations, makes the same distinction. It says a phased approach reduces the risk of cutover issues because you can adjust based on feedback, and that it is easier to roll back. For an all-at-once cutover, it advises extensive testing and a clear decision on who can call for a failback.

Switching all stores at once may suit you when IT is managed centrally, you have fewer stores or the old system must be retired by a fixed date. In that case, rehearsing the cutover and recovery process becomes especially important

The table below compares both approaches to help you decide which works best for your stores.

Include both a typical store and a difficult one in your pilot, and set the pilot size and the time between waves to suit your own estate.

How to create a POS cutover plan

A POS cutover plan sets out the steps for moving live trading from the old system to the new one. AWS's cutover guidance, written for cloud migrations, follows the same pattern of a freeze, a final backup, a final data sync and testing before the switch is marked complete. It also advises choosing a time with few users while support teams are available, which in a store means a quiet trading period with your support staff on hand.

1. Confirm the freeze window, store communications and escalation contacts.

2. Take a final backup or export of the old system and record the time and version.

3. Capture the last changes to stock, prices, orders and transactions.

4. Load the final data and reconcile counts, key values, rejected records and opening balances.

5. Switch on live payments, connected systems, devices and staff access.

6. Run the agreed checks on the store's own equipment, including a sale, a payment, a receipt and a stock update.

7. Hold the go or no-go decision against written criteria, and record who decided and when.

8. Monitor the first trading period, including exceptions and payment results, through to the first closing.

Prepare for problems on the day, such as a late data file, a failed device, a backlog in a connected system, a staff access problem, an overrun of the freeze window or a critical test failure. Give each one an owner, a time limit and a communication route, and confirm your payment provider's support hours before you set the date.

What should a POS rollback plan include?

A POS rollback plan sets out which failures trigger a rollback, who makes the decision, how you restore a working way of trading and how you reconcile the sales, refunds, payments and stock changes recorded since cutover. Rehearse it before go-live.

AWS's cutover guidance recommends agreed rollback checkpoints, a plan for handling the data and a named person who decides between fixing the fault in the new system and rolling back. It also warns that once the new system has accepted transactions, the old system falls out of date, so restoring it means bringing those records back across. Cover these areas in your rollback plan.

• Triggers: Set limits in advance for failures such as declined card payments, wrong prices or tax, missing or duplicate sales, totals that fail to reconcile or a connected system going down.

• Authority: Name a decision-maker and a deputy, give each store the power to stop trading and choose an owner for communications.

• Recovery method: Use the old system if it is still usable and you understand the state of its data, otherwise use an approved manual process. List the access, hardware, settings and support contacts you need, and the recovery time you measured in rehearsal.

• Records created since cutover: Capture every sale, void, refund, payment and stock change, and decide how to re-enter or replay them without creating duplicates.

• Evidence: Keep backups, timestamps, logs, reconciliation results, the decision log and the approval to resume trading.

If you roll out in stages, a rollback can also pause further stores and keep the problem to the stores you have already switched.

Rehearse the plan first as a walk-through of roles and decisions, and then, where practical, as a test of the recovery steps outside live trading.

What to check after go-live

Work through these checks on opening day and through the first week of trading.

• Before opening, confirm that each device is connected, the correct store is selected, payments are in live mode, opening floats are entered and staff have the right permissions.

• During trading, log payment, device, stock and connected-system exceptions with the time, store and owner.

• At closing, reconcile each register and tender total, then compare sales, tax and stock reports with the finance records.

• Repeat the closing checks daily in the first week, and review training gaps, faults and open exceptions before the next wave starts.

• Update the runbook and training materials with what the first store showed.

When is a POS migration ready to go live?

Your first store is ready to go live when all the required checks are complete, outstanding issues have been reviewed and the recovery plan is in place. Before making the final decision, confirm that the data, hardware, payments and integrations have passed their tests, with results and approvals recorded. Any unresolved issues should have a clear owner and an agreed action.

Once the first store goes live, check that transactions, stock records and financial reports are accurate before extending the rollout to other locations.

Fynd POS supports retailers through this process with data imports for inventory, customers, SKUs and users, integrations with existing ERP and OMS systems, and options for phased rollouts and parallel runs. The cloud-based system handles billing, inventory, loyalty and returns across mobile devices, tablets, desktops and compatible existing terminals. Fynd also provides on-site assistance during go-live and monitors store performance after launch. For retailers looking to extend their in-store capabilities, Fynd Store OS also supports endless aisle, clienteling and self-checkout.

If you're planning to switch your EPOS system, explore how Fynd POS can support your migration, from preparing your data to getting your stores live.

Explore Fynd POS