It is Monday morning in a 20-store fashion chain. The procurement team has just sent the final shortlist of three POS vendors. The operations director is thinking about Tuesday. What happens Tuesday when the system goes live in the flagship? What happens Wednesday when the team is running on pure habit and the new system's behaviour is completely unfamiliar? What happens if the integration with the ERP breaks on day two?
That fear is rational. It is also the reason most POS migrations fail. The fear drives retailers to demand feature parity. "Give us everything we have now, just on a newer system." Feature parity feels safe. It is not. It guarantees that Tuesday will feel exactly like today, which is the opposite of what most retailers need.
A POS migration is the only window most retailers get to reset their operating model for the next decade. The difference between a migration that just swaps the logo and a migration that actually steps the operation forward comes down to how that Tuesday question is answered. Not by ignoring the fear. By building the migration around it.
Start with understanding, not cutover
Before any vendor is contacted, there is a prior question: what is the operation actually struggling with today?
A retail chain that has been running the same POS for eight years has built workflows around its constraints. The manager runs the evening reconciliation at 10 PM because the system is slow during store hours. The regional team does a manual price change sweep on Friday because the price update cycle takes too long. The cashier has learned a seven-step workaround for the one refund scenario the system does not handle cleanly. None of this is written down. It is just how things are done.
When migration planning starts, the procurement brief is usually written by people who do not do those 10 PM reconciliations. The brief asks vendors to match the feature set of the current system. The features the current system cannot do are not on the brief, because nobody knew to ask. The migration goes live, and the chain ends up running the same workarounds on the new vendor. Five years locked in.
The retailers that escape this trap start differently. They begin by mapping what the operation actually needs. A week of store visits. A review of what time is going where. A look at which workflows are fragile, which exceptions consume management attention, which decisions are made on incomplete information. This is not a feature audit. It is an operating model audit.
Out of that audit comes a document that describes what the operation should feel like two years after go live. Not the features. The behaviours. How fast does an exception get resolved at the till. How much manager time goes to exception handling versus floor coverage. How quickly does a price change reach every store. How does the chain learn from itself between Monday and Friday. The vendor list is built from that document, not from a Gartner quadrant.
The companion read here is AI native retail is not a feature, it is an organizational decision, which walks through this same logic at the company level. The urgency there is the same urgency here: the system you choose shapes the operation you can run for the next five years. The architecture matters more than the checklist.
Pilot where you are most nervous
In a 20-store chain, there is usually one store that keeps the operations team up at night. The data is messy. Staff turnover is high. Exception cases pile up. Managers there are accustomed to improvising. Most pilot programs run in the opposite store: the new flagship with the calmest team and the cleanest operations.
This is backwards. The point of a pilot is to surface the failure modes that will appear at scale, not to produce a clean reference video. A pilot in the steady flagship teaches nothing because nothing was at risk. A pilot in the store that scares you teaches you what you need to know before going chainwide.
When Vendor A's system went into the nervous store, it broke on the first Wednesday. A workflow that was not in any plan because it was just "how we handle Saturday exceptions." The pilot failed in real time. But it failed before the deployment wave, not after. The team had time to work with Vendor A's product team. The workflow got added in days because the vendor's release cycle was fast. By week two, the store was running cleanly. By wave two, the deployment team knew how to handle similar exceptions everywhere else.
This is the information you need. Not whether the system works in ideal conditions. Whether it works when your actual operations meet it. Whether the vendor is responsive when the plan breaks. Whether the cycle from "we found a problem" to "we deployed a fix" is measured in days or months.
The store you are most nervous about is the store you need to pilot in. Anything else is a marketing video disguised as a pilot.
Run the migration in waves, not one weekend
The legacy approach was a Saturday night cutover. Every store went live at the same time. This made sense when old and new systems could not coexist. Modern AI native POS systems can run in parallel. The old system keeps running. The new system runs alongside. After three days, if the new system is holding, the old one turns off. If something breaks, you flip back to the old system in an hour.
Run the migration in waves of five to ten stores, with one week between waves. Each wave teaches the rollout team something. After wave one, you know the data migration method works at scale. After wave two, you know the integration connectors are stable. After wave three, you know the staff training approach actually sticks. After wave four, the team is fast enough to make wave five nearly painless.
The old approach absorbed all the problems at once. A thousand exceptions on Monday morning. Everyone in crisis mode. Solutions made under pressure that would not hold on Tuesday. By contrast, a wave approach compresses the learning curve. The knowledge from each wave improves the next one. The 20-store chain does not hit five catastrophic failures across five weekends. It hits five controlled learning moments across five weeks.
The benefit is not just risk reduction. It is speed. A single weekend cutover forecloses the learning curve entirely. A wave-based approach brings it forward and shortens the total time to stable operations.
The first ninety days are not a victory lap
The system boots up in the final store. Vendors like to call this "go live." They like to pack up and move to the next customer. Internal teams like to call it "migration complete" and return to business as usual. This is the moment the actual migration starts.
Go live is when the new operating model begins to settle. For three months, the chain is not using the system the way it was scoped. It is using it the way the old system worked. Behaviours do not change overnight. Muscle memory runs deep. The cashier still looks for the button that was in the old system, even though the new system does not have buttons, it has an AI assistant that is faster.
The retailers that get this right treat the first quarter after go live as an active migration period. A small team stays in place. One week after go live, the team reviews what changed and what did not. Are managers actually spending less time on reconciliation, or are they still running the old process out of habit? Are store teams using the AI alerts to get ahead of problems, or are they still chasing exceptions the old way? Is the ecommerce integration working seamlessly, or do people have workarounds?
Most importantly: are the behaviours that were supposed to change actually changing? The system is just the substrate. The migration is the workflow change. Going live without an active ninety-day period to embed those changes means the retailer runs a 2030 system with 2018 workflows on top of it. That is a logo change, not a migration.
The vendor decision is the strategy decision
Before the vendor conversation, there are three architecture questions to ask. Not feature requests. Not demo requests. Architecture questions.
Where does the AI live in the till interface? Is it embedded in the main workflow, or is it a side panel you have to switch to? Systems that embed AI into the main workflow change behaviour because they change where attention goes. Systems that make AI optional keep old workflows intact.
Is the data model unified between till and backoffice, or does the system reconcile overnight? If you are asking managers to make Thursday decisions based on Friday data, you are running legacy operations. If the system shows accurate numbers as of thirty seconds ago, the decision-making changes.
How long is the cycle from a customer feature request to a deployed change in the production till? Some vendors ship every two weeks. Some vendors ship every six months. Over five years, this difference compounds into either a system that evolves with your needs or a system that locks in what was scoped on day one. The full framework for the first two questions is laid out in AI native POS. The third question is what most retailers skip and most regret skipping.
These three questions tell you what five years on that vendor will actually feel like, before any contract is signed.
The Nordic layer
A Nordic POS migration carries compliance constraints that migrations in other regions do not. Sweden's kassaregisterlag, Denmark's bogføringsloven, Norway's bokføringsloven, and the Nordic specific receipt and audit obligations all need to migrate cleanly. A vendor that handles these as a regional add on will produce a migration that works in theory but limps in practice. A vendor that built them in as foundational constraints produces a migration that holds.
The other Nordic layer is integration density. Most Nordic chains run a stack that includes a homegrown ERP, a regional ecommerce platform, an OMS, and at least one staff scheduling tool. These systems are deeply woven in. The POS migration cannot break those connections. A vendor with an integration that "exists on a roadmap" will produce a migration that requires workarounds. A vendor with live integrations that work today produces a migration that is actually smooth. The deeper view is in Karo for compliance and the integrations posture guide.
What most migrants get wrong
Feature parity is a trap. A vendor that promises to ship everything your current system has is promising to ship you the same operation, just on a newer logo. That is not the point of a migration. The point is operating model improvement.
Roadmaps are a trap. A vendor selling you roadmap items instead of current product is selling you something that may never ship. There is always a "we are building that." Buy what is in the till today. Treat the roadmap as a tiebreaker, not as an asset.
Integrations are a trap. A vendor listing three hundred integrations on the marketing page but unable to demonstrate two of yours working in a sandbox is selling a directory, not an integration. Ask to run two of your integrations live in a demo, not on a slide. See whether they work. See whether the vendor's support team can troubleshoot when something is wrong.
The moment is now
A POS migration is the only window most retailers get to redesign the operating model. The contract opens. The data layer is in motion. The store team is willing to relearn workflows. The political resistance to change drops to its lowest point of the decade. This is the moment.
Migrating from one AI added system to another AI added system spends that window on nothing. The next five years are locked in to the same operating ceiling. Migrating from an AI added system to an AI native POS uses the window for what it is: the once a decade chance to step the entire chain forward. The vendor decision is the strategy decision. The procurement decision follows. Not the other way around.
If you are scoping a POS migration in the next twelve months, the highest leverage hour you can spend right now is the Karo Operations Audit. Twenty questions, ten minutes, and a personalised report on what your current operation costs you in time at the till and what would change on an AI native system.