Migrate Badges Between Issuers Without Losing Evidence

Quick answer: To migrate badges between issuers without losing evidence, export credential definitions, recipient identifiers, issued records, criteria, evidence references, status history and verification IDs before changing systems. Validate imports with checksums or record counts, preserve old verification links where possible and test active, expired, revoked and corrected badges. Do not treat image files or a recipient CSV as a complete migration.

Badge migration is a records project, an identity project and a communications project. The visible badge image is usually the least important part. Teams planning to migrate badges between issuers without losing evidence need to preserve what the achievement means, who issued it, how it was earned and whether it remains valid. A rushed migration can create duplicate badges, broken evidence and verification links that no longer explain the record.

Plan how to migrate badges between issuers without losing evidence

Create an inventory before contacting vendors. List issuers, credential definitions, versions, recipients, issue dates, expiry rules, revocations, evidence types, verification domains, integrations and support obligations. Mark sensitive evidence and links that depend on the old LMS or storage service.

Use digital badge ecosystems and badge implementation and management to map dependencies. Assign an owner for data extraction, privacy review, technical import, verification continuity and recipient communication. Freeze nonessential template changes during the migration window. A controlled baseline makes reconciliation possible and reduces the chance that records change while they are being moved.

Migrate badges between issuers without losing evidence: data checklist

The distinction between digital badges and simple image files is central to this checklist.

Export complete definitions and issuance history

Request machine-readable exports for definitions, issued records, recipient data, status changes, evidence references and audit logs. Include field documentation and enumerated status values. Ask whether the export contains vendor-specific extensions and how they map to the target system.

Review the examples in digital badge examples and examples of digital badges to identify metadata that users and verifiers rely on. Export visual assets separately but keep their relationship to each definition. A spreadsheet of names and badge titles may support reissuance, but it does not preserve original issue identifiers, evidence or revocation history.

Preserve criteria and evidence deliberately

Evidence may be embedded, linked to the LMS, stored in cloud files or generated from assessment systems. Classify each source as public, authenticated, expiring, sensitive or unavailable. Decide whether to copy the evidence, keep the original link, create a durable archive or replace it with an approved summary.

Do not make private student work public during migration. At the same time, avoid importing a badge with a broken criteria page. The target record should explain what the recipient did and how the issuer judged it. The guidance on secure badge issuance and verification can support privacy and trust decisions. Document any evidence that cannot be transferred and the reason.

Map identities and prevent duplicates

The same person may have several emails, accounts or names. Use stable internal identifiers where lawful and available, then create a controlled matching process. Separate automatic matches, probable matches and records requiring review. Do not merge people only because their names are similar.

Recipient access after migration matters as much as database matching. Allow users to claim or recover records through a durable address, especially when institutional accounts have closed. The target platform’s model should align with credential management software and digital credential management software. Keep a crosswalk between old and new identifiers for support and audit without exposing it publicly.

Decide between transfer, import and reissuance

Some systems can import portable credential records and retain original issuer information. Others create a new credential under the target issuer. Those are different outcomes. Reissuance may be appropriate when the legal issuer remains responsible and the target platform becomes its service provider, but the record should not imply a new achievement date.

Document whether the migrated badge keeps its original issue date, identifier and status. If the target system cannot represent a field, decide whether to store it as evidence, an extension or a migration note. Concepts from digital badge platforms and badges versus certificates can help clarify what is being transferred. Avoid silent transformations that change the meaning of the award.

Maintain verification continuity

Old badge links may appear on resumes, social profiles, portfolios and employer systems. Inventory the verification domains and URL patterns before exit. Ask the former provider about redirects, read-only hosting and export of verification identifiers. If you control the domain, plan permanent redirects to the corresponding new records.

Test active, expired, revoked and superseded badges from an external browser. A redirect should land on the exact record, not a generic homepage. The lifecycle considerations in expirable digital badges are useful here. When continuity is impossible, publish a clear verification transition page and give recipients replacement links. Do not leave old URLs displaying an ambiguous error.

Validate how to migrate badges between issuers without losing evidence

Start with one credential definition that includes normal records, name changes, expiry, revocation and different evidence types. Compare source and target counts, dates, status, recipient identity and links. Review a random sample and every exception. Record discrepancies and repeat the import only after understanding them.

Then migrate a larger wave and reconcile again. Use automated reports, but include human review of meaning and display. A record can pass a field count and still show the wrong issuer name or criteria. The program view in digital badges for training and digital badges in higher education can help select representative programs. Keep the old system read-only until acceptance criteria are met.

Coordinate integrations and issuance cutover

Pause or reroute automated issuance during the transition. Otherwise, completions may continue entering the old platform while historical records move to the new one. Define the final event time, queued jobs, retry behavior and source of truth. Reconcile completions around the cutover window.

Update LMS, HR and analytics integrations in a test environment first. Review LMS badges for course-driven dependencies. Keep idempotency keys so replayed events do not create duplicates. After launch, monitor both missing and double issuance. The migration is not complete until new records, status changes and support workflows operate correctly in the target platform.

Communicate with recipients and verifiers

Tell recipients what is changing, when, what action is required and how old links will behave. Avoid asking everyone to claim a new badge when records can be transferred safely. Provide support for lost access, changed email and mismatched names. Explain that the achievement itself has not changed when only the service provider changes.

Frequent external verifiers, partner institutions and employers may need a separate notice. Include a verification contact and migration period. Sharing contexts such as LinkedIn digital badges make clear why old links remain in circulation. Communications should be coordinated with technical redirects and support readiness, not sent before the new records are testable.

Retain audit evidence and close the old system safely

Store source exports, field mappings, transformation rules, exception decisions, validation reports and approvals according to retention policy. Record who authorized the final cutover. The archive should allow the organization to explain how an old record became a new one without retaining unnecessary personal data forever.

After acceptance, remove obsolete integration keys and administrator accounts. Confirm contract termination, deletion certificates and any read-only verification obligations. The enterprise perspective in enterprise credential management can support closeout governance. Keep a documented route for handling future disputes about pre-migration credentials.

Create transformation rules before importing

For every source field, define the target field, data type, allowed values, default, validation and treatment when missing. Keep transformations deterministic and version-controlled. Avoid manual spreadsheet edits that cannot be reproduced or audited.

Run the rules against a copy of the source data and produce an exception file. Review unusual dates, unsupported characters, orphaned evidence and unknown status values. The target import should stop or quarantine invalid records rather than silently dropping fields.

Test recipient ownership after migration

Ask recipients to access records with current, changed and closed email accounts. Confirm that they can recover access without creating duplicates and that ownership is not transferred to the wrong person. Include minors, shared institutional addresses and users with several names where those cases exist in the program.

Support teams should see the old and new record relationship without exposing the full migration crosswalk to recipients. Durable ownership is a core acceptance criterion because a technically complete database transfer still fails when learners cannot reach their achievements.

Add a formal launch checkpoint

Before production, review the workflow with the program owner, technical owner, privacy lead and support team. Confirm data ownership, exception handling, monitoring, recipient communication and rollback. Record unresolved risks with an owner and due date rather than accepting informal assumptions.

Repeat the checkpoint after the first live cohort. Compare expected and actual support volume, data quality, delivery and verification. Small operational changes made early can prevent recurring manual work as the program grows.

Add a formal launch checkpoint

Before production, review the workflow with the program owner, technical owner, privacy lead and support team. Confirm data ownership, exception handling, monitoring, recipient communication and rollback. Record unresolved risks with an owner and due date rather than accepting informal assumptions.

Repeat the checkpoint after the first live cohort. Compare expected and actual support volume, data quality, delivery and verification. Small operational changes made early can prevent recurring manual work as the program grows.

Add a formal launch checkpoint

Before production, review the workflow with the program owner, technical owner, privacy lead and support team. Confirm data ownership, exception handling, monitoring, recipient communication and rollback. Record unresolved risks with an owner and due date rather than accepting informal assumptions.

Repeat the checkpoint after the first live cohort. Compare expected and actual support volume, data quality, delivery and verification. Small operational changes made early can prevent recurring manual work as the program grows.

Frequently Asked Questions

Can badge images be migrated on their own?

They can be copied as design assets, but they do not preserve recipient identity, criteria, evidence, issue date or status. A complete migration needs structured records and lifecycle history.

How do you migrate revoked badges?

Import them with the original issue data and revoked status where the target platform supports it. Test that verification clearly shows the status. Do not reissue them as active records.

Can you migrate badges between issuers without losing evidence when the old LMS is closing?

Yes, but evidence must be copied or archived before the LMS is decommissioned, subject to privacy and retention rules. Replace temporary course links with durable approved references. Document anything that cannot be preserved.

Should recipients receive new issue dates?

Usually not when the achievement itself is unchanged. Preserve the original issue date and record the migration separately. A new date could imply the learner completed the requirements again.

Final Thoughts

To migrate badges between issuers without losing evidence, preserve definitions, identity, dates, status, criteria, evidence and verification continuity as one connected record. Validate in waves, control the issuance cutover and communicate clearly with recipients. Treat reissuance as a governed decision, not a technical shortcut. Keep an audit trail and close the former system safely. DigitalCredentialPlatforms.com can support migration planning with resources on badge ecosystems, management software and secure verification.