When migrating access control systems, data gaps, production issues, and edge cases can lead to badges failing to work. This article highlights three common causes and explains how to plan migrations more effectively.
If we look at an example of a large industrial park, an employee badge rarely belongs to just one system.
The employee record may begin in SAP, Active Directory or an HR platform. A separate application stores the photo. Badge-production software selects the design and encoding profile. The physical access control system distributes the relevant information to controllers and readers across multiple sites. The same badge may also support time recording, secure printing, payment or machine access. Quite often, different internal teams and external integrators are responsible for each part of this environment. And not every organization’s landscape looks the same.
During a migration, they must all keep exchanging the right information at the right time. A problem somewhere in this landscape might present as something that seems quite small: the employee badge does not work.
In our experience, several things can cause this symptom and need to be considered during a migration.
Access control migrations often use scheduled imports, SFTP transfers, APIs, directory synchronization and database processes. A completed transfer does not always produce a complete operational result.
We have seen import files marked as processed while individual records still required investigation. In another case, the main employee record updated while its location assignment remained unchanged. Duplicate entities have prevented selected employees from synchronizing. A PIN has also reached an access control system with a different value, leaving the badge holder unable to enter the site.
To detect these problems, we validate the data at field and relationship level. We map how each person is identified across the system landscape, define the authoritative source for every relevant field and verify how changes propagate through connected records.
UIDs, card numbers, locations, profiles, PINs and credential statuses need documented mapping rules. Monitoring must also show which records failed and whether a process can be repeated safely.
This is where cooperation between integrators becomes essential. The HR provider may confirm that the correct data was sent. The identity platform may confirm that the employee exists. The access control provider may still receive an unexpected value. Resolving the issue requires a shared view of the complete path.
Employee master data represents only part of the information required for badge production.
The production environment may also need a photo, card profile, layout, UID, credential assignment, activation status and production history. Some information may remain in a separate image platform or in the previous badge-production system.
A person can therefore appear correctly in the new administration system while their photo is unavailable to production. The required card profile may be missing. Existing UIDs may still need to be imported. Production data may remain in the previous environment.
The order of the migration matters. Photos, person records, profiles and credential assignments must be transferred in a sequence that preserves their relationships. The team must also decide how active, inactive, lost and previously produced cards will be represented in the target system.
Producing a real badge is an important migration test. It shows whether the employee record leads to the correct photo, card design, encoding and credential status. The resulting badge must then provide the identifier expected by the access control system.
Standard onboarding usually receives the most attention during planning. Replacement cards, status changes and other lifecycle events often reveal the missing dependencies.
When an employee loses a badge, their personal information may remain unchanged. The replacement request must still deactivate or replace the previous credential, trigger a new production job, apply the correct profile and transfer the new identifier to the access control system.
We have seen a replacement request reach the integration process without starting a new production job. Because no personal data hadchanged, the production status retained its previous value and the downstream process did not identify the badge for re-production.
Similar problems can arise when an employee changes site, a credential is deactivated, a temporary badge has no permanent owner or an existing card receives another RFID application.
These processes cross several areas of responsibility. The identity team manages the person and credential record. The production team controls printing and encoding. The access control integrator manages the target access system. Another partner may be responsible for readers, controllers and physical access points.
Each process therefore needs a defined trigger, expected system response and responsible owner. Migration tests should include common exceptions as well as the first successful pilot badge. This does bring up the question about the leading system, but that is a topic for another day.
Two previously published evolutionID projects show how these dependencies can be managed while badge and access operations continue.
In one multi-site environment, employee data originated in SAP and supplied a central identity-management platform. Photos, access rights, badge applications and production processes had to remain aligned across remote locations. Existing and newer reader technologies operated at the same time, so multi-technology credentials supported a phased rollout.
Another project integrated a new identity and badge-production environment with an established physical access control system. Existing employee photos were migrated and a stock of pre-encoded MIFARE DESFire cards remained in use. Once that stock was exhausted, the new environment took over the complete encoding process. The project also involved UID conversions, number ranges and interfaces to secure printing.
Both projects followed the same practical principles: preserve suitable existing components, divide the migration into controlled stages and coordinate continuously with the relevant access control and technology partners.
The work begins with an accurate picture of the existing environment. This includes identity sources, badge-production systems, RFID technologies, credential applications, access control integrations and operational processes.
TAG Analyzer supports the technical analysis of existing RFID credentials. It documents information such as card technology, UID, applications and accessible data. This helps determine which badge populations can remain in use, which require an update and which need to be replaced.
The migration team then maps the relationships between systems. It defines the authoritative source for each data element, the required transformations and the expected response to events such as onboarding, replacement and deactivation.
Where existing credentials are suitable for continued use, IDkiosk can support controlled updating or re-encoding. The rollout can then proceed through defined migration groups, with data reconciliation, badge-production tests and checks at representative access points after each stage.
Throughout the project, evolutionID maintains the overview across identity data, badge production, RFID credentials and access control integration. We work with the integrators responsible for HR systems, access control, readers, controllers and site infrastructure so that decisions remain aligned across the complete environment.
Keeping the complete system in view
Complex access control migrations connect technologies and responsibilities that have developed over many years.
evolutionID combines identity management, badge production, RFID analysis, credential updating and integration experience. This helps us identify dependencies, coordinate the relevant specialists and plan a migration that protects ongoing badge and access operations
