Meal vouchers in Europe / How to migrate a meal voucher programme to a new issuer

How to migrate a meal voucher programme to a new issuer

Migrating a live meal voucher programme is not a card replacement exercise. The cards are the easy part. What breaks is the merchant list, the employee data and the funding cycle, and the reason migrations are hard is that the benefit cannot be switched off while you work. Employees eat every working day, and a gap in service is visible to every one of them at lunchtime.

Last reviewed: 28 August 2026. Written for benefit platforms and voucher issuers changing issuing partner, whether by choice or not.

Why programmes migrate

Three reasons account for most of them, and only one is a decision.

The partner fails or is forced to change. Benefit card providers do not usually hold the licence themselves, so the licensed institution behind the card is a single point of failure. This is not hypothetical in European benefits: providers have had to move issuers when their partner collapsed, and some have done it more than once.

A regulatory deadline forces the format. An issuer with paper volume and no card product does not have a migration problem, it has a product problem. France is the current example, with paper ceasing to be usable at the end of February 2027.

Economics change. When a regulator caps what an issuer may charge merchants, as Italy did at 5 percent, the cost per transaction stops being a background number.

What actually has to move

In rough order of difficulty, which is the reverse of the order people expect.

The merchant list is the real project

In any market where the law ties acceptance to merchants holding a contract with the issuer, that list is the licence to operate. It is also, in most businesses, the data set that has grown for years without a single owner: duplicates, closed businesses, merchants recorded under a trading name in one system and a legal name in another, and identifiers that came from an acquirer rather than from you.

Two questions decide how painful this is.

Do you hold the list, or does your issuer? If the authoritative copy lives inside the incumbent platform, extracting it is a negotiation as much as an export. If it lives in your own system, the migration is far shorter.

What identifies a merchant? A merchant identifier issued by one acquirer does not necessarily match the same shop seen through another. Any list keyed only on identifiers from the outgoing arrangement needs a second key, usually the legal registration number, before it can be moved.

Keep the authorisation decision on your side

The single design choice that makes future migrations cheap is where the accept or decline decision is made.

If your rules live inside the issuing platform, then every platform change is a re-implementation of those rules, tested from scratch, in someone else's configuration language. If the decision is made by your own system, with the platform passing each authorisation for a verdict, the rules do not move at all. Only the transport changes.

That is the practical case for shared authorisation beyond compliance: it turns the issuer into a replaceable component. Your merchant list, your ceilings, your exclusions and your product logic stay where they are maintained. The interface is documented in the shared authorisation documentation.

Running the migration without a gap

Six steps, sequenced so the benefit never stops.

1. Freeze the merchant list and clean it. Deduplicate, drop closed businesses, add a second identifier. Do this before anything technical starts, because everything downstream depends on it.
2. Stand up the new programme in parallel. New cards issued, not yet funded, not yet distributed. The old programme continues untouched.
3. Run one funding cycle on both. Fund the new programme for a small pilot group while the old one carries everyone else. This is where reconciliation differences surface, and they always do.
4. Move employees in waves, not on a date. By site, by country or by employer, so a problem affects a group rather than the workforce. Virtual cards make each wave a same day event.
5. Sweep unspent balances. Decide early whether value transfers or the old card stays live until spent. Both work, but the choice drives employee communication, and the wrong answer produces complaints on the first Monday.
6. Close the old programme only after a full cycle. Not after the last card is issued.

What goes wrong

Treating the deadline as the finish line. If the plan has everyone moved on the final day, there is no room for the group that does not activate. Aim to be finished a cycle early.

Assuming employee data is current. Migration is when a benefits database meets reality: leavers still listed, changed working patterns, people at a site that closed. Reconciling headcount is part of the project, not a precondition someone else handles.

Migrating the rules by hand. Ceilings, excluded categories and market specific conditions rewritten into a new platform from memory rather than from a specification is how a programme quietly stops matching the law it was built for.

Before starting, settle the acceptance model for each market you operate in: see open loop or closed loop. For a new programme rather than a move, see how to launch a meal voucher card programme.