Migrating from a legacy labelling system to enterprise label management

Most legacy labelling systems are replaced for good reasons. The software is out of support, the server it runs on is ageing, or the people who built it have moved on. The new platform is rarely the hard part of the migration. The hard part is everything the old system does that nobody wrote down: a date calculated inside a template, a field filled by a script, a printer that only works with one driver.

This checklist follows the order the work is usually best done in. Each step produces something that can be checked before the next one depends on it, and the operation keeps printing throughout.

1. Establish what the current system really does

Start with an inventory, then check it against what actually prints.

• Every template in use, where it is stored, and which ones are copies of each other
• Every source of label data: ERP, WMS, MES or LIMS, databases, spreadsheets and manual entry
• Every trigger and integration: file drops, database links, scheduled jobs and middleware
• Logic held in templates and scripts, such as date calculations, check digits, conditional fields and serial counters
• The printers, drivers, firmware and media each site and line depends on
• The people who understand the system, and what happens when they are away

Comparing a sample of real printed labels with the templates that produced them is the quickest way to find behaviour that was never documented.

2. Map every label field to its source and owner

Each field on a label should trace to a system and a person responsible for it. In a legacy estate, one label often draws on several places at once: a product master in the ERP, a batch number from the line, a date typed by an operator and a customer code kept in a spreadsheet.

• For each field: the source system, the owner and the format the label expects
• Fields typed at the printer, and whether a system could supply them instead
• Customer- and market-specific rules, such as date formats, languages and label variants
• GS1 identifiers and their rules: GTINs, SSCCs, Application Identifiers and check digits

This map becomes the specification for the integrations in step five and the test cases in step seven.

3. Rationalise templates before migrating them

Moving every legacy template one for one carries the duplication into the new system. Legacy estates often hold many more label files than genuinely different labels: copies made for one customer, line or pack size that differ only in a logo or a field.

• Group templates by what genuinely differs: layout, regulatory content and customer requirements
• Move the differences into data and rules, so one template can serve many products
• Give each template an owner and an approval route
• Retire templates that are no longer printed

The aim is a template set small enough to version, test and change with confidence.

4. Decide the target architecture

The choice between cloud, on-premises and hybrid follows from the sites, the network and what has to keep printing when a connection fails.

• Where templates, rules and data will live, and who can change them
• Central or local print services, and what keeps each site printing during an outage
• How the new system will be secured, backed up and recovered
• Licensing and infrastructure sized for the estate as it is expected to grow
• Who will support the platform after go-live, inside the business and outside it

Write these decisions down as the target architecture. They shape the integration design in step five and the printer preparation in step six.

5. Design integrations for failure

Integrations are where legacy systems tend to hide the most undocumented behaviour, and where a new system needs the most deliberate design.

• Each trigger: the business event, the system that raises it and the data it carries
• The method: API, web service, database connection or file interface
• What happens when a print fails, a printer is offline or data is missing
• Monitoring and alerts, and who receives them
• An owner for every interface, on both sides

A failed print request should raise an alert that reaches a named person, with enough detail to act on. The guide to integrating label printing with ERP systems covers these decisions in more detail.

6. Prepare printers, media and sites

• Printer models, firmware and drivers that the new platform supports
• Fonts, logos and graphics stored on printers, which legacy templates sometimes depend on
• Labels and ribbons matched to each application and environment
• RFID encoding, where it is used, tested with the tags actually in use
• Network access from each site to wherever the print services will run

Test on the real printers at each site early. What a design tool shows and what a printer produces can differ in ways that only appear on the hardware itself.

7. Agree how the output will be tested and accepted

Decide what counts as a correct label before anything is migrated, and how that will be shown.

• Side-by-side comparison of old and new output for each template and data variant
• Barcode verification against the relevant GS1 specification, with print quality graded to ISO/IEC 15416 for linear symbols and ISO/IEC 15415 for 2D symbols
• End-to-end tests from the business event to the printed and scanned label, including the failure cases from step five
• In regulated environments: a validation plan, documented test evidence, change control and a review of the audit trail
• Sign-off by the owners of the templates and data, as well as IT

8. Migrate in stages, with old and new in parallel

• Move by line, site or label type, starting where the risk is lowest and the lessons are most useful
• Run old and new side by side until the new output is proven
• Keep a tested route back to the old system for each stage
• Freeze template changes in the old system while each stage moves
• Train people on their own workflow before their stage goes live

Each stage should leave the operation printing correctly, whatever happens in the next one.

9. Hand over and decommission

• Documentation of the architecture, interfaces, templates, rules and support procedures
• Clear ownership: who approves template changes, who supports the platform and who owns each interface
• Decommissioning: old templates, scripts, scheduled jobs and access removed, with a record of what was retired
• A review once each site has run on the new system for a while, to catch what testing missed

An old system left running in the background is easy to fall back on and hard to keep in step, so retiring it is part of the project.

Where to start

Most of this checklist depends on step one. A labelling health check covers it: the current software, templates, data, integrations, infrastructure, printers, workflows, supportability and compliance requirements, ending with a current-state architecture, the main risks and a staged recommendation. From there, the legacy modernisation approach and the design of the label management system follow from what the operation needs.