How to Migrate Badges From One Platform to Another

Quick answer: To migrate badges from one platform to another, inventory every badge class and issued record, export structured metadata, map fields to the new system and test verification before moving all recipients. Preserve issue dates, criteria, evidence, status and stable identifiers wherever the destination allows it. Review expirable digital badges when mapping renewal and expiration rules. A safe migration also includes learner communication, exception handling and a plan for old verification links.

Badge migrations are data and trust projects, not simple file transfers. The badge image may move while criteria, evidence, issuer identity or revocation history gets lost. Learners may have accounts under old email addresses, creating duplicates in the new platform. A staged plan to migrate badges from one platform to another gives the issuer time to validate records and protect verification.

Plan before you migrate badges from one platform to another

Start with the reason for moving. Common drivers include pricing, weak integrations, limited administration, a merger, a new LMS or a need for more portable credentials. The goal determines what “successful migration” means. A governance-led move should test permissions and audit history, while a portability-led move should focus on exports, wallets and verification links.

Create a complete inventory. List badge templates, versions, recipients, issue dates, expiration dates, revocations, evidence links, criteria pages, tags, issuer profiles and delivery status. Include inactive badge classes because historical records may still need verification. The broader guide to digital badge implementation and management can help identify lifecycle data that teams often overlook.

Separate source data into three groups: required, desirable and unavailable. Required fields should include the achievement, issuer, recipient reference, issue date and status. Desirable fields may include evidence, alignment, tags and sharing activity. Unavailable fields need a documented decision. Some platform-specific analytics or claim events may not transfer at all.

Assign ownership before extraction. A program owner should approve credential rules, a technical owner should manage exports and imports, and a privacy owner should review recipient data. Support staff need scripts for learner questions. Without named owners, exceptions can sit unresolved while the old contract approaches its end date.

Badge migration methods compared

The method may differ across record types. Active badges might be imported through an API, while old records are preserved in a read-only archive. A mixed model works when the issuer documents what recipients and verifiers can expect.

Export data needed to migrate badges from one platform to another

Ask the source vendor for a data dictionary before exporting. A CSV may contain fields with unclear meanings, while a JSON or standards-based package may preserve richer metadata. Confirm character encoding, date format, time zone, identifier rules and how revoked records appear.

For each badge class, capture the name, description, criteria, image, issuer, version, tags, alignment and expiration policy. For each issued badge, capture recipient reference, issue date, expiration date, evidence, status, revocation reason and original identifier. If the platform supports baked badges or standards-based exports, preserve those files as an archive even when the new platform uses an API import.

The article on digital badge structure provides context for the fields that give a badge meaning. A PNG alone is not a complete migration source. It may contain embedded metadata, but the issuer still needs a reliable record of status and recipient association.

Export issuer profiles and criteria pages as well. Old badges may link to hosted pages that disappear after account closure. Copy the text and note the original URLs. Decide which pages will redirect, which will remain archived and which need a new permanent location.

Keep the original export unchanged. Work on a copy and record every transformation. That gives the team a baseline for troubleshooting and supports rollback if mapping errors appear later.

Field mapping and data cleanup

Build a source-to-destination map. For every source field, specify the target field, transformation rule, default value and error condition. Don’t silently place missing data into unrelated fields. A note field can preserve context, but it shouldn’t replace structured status or evidence data.

Normalize dates and identifiers carefully. A date without a time zone can shift when imported. Leading zeros may disappear when spreadsheets interpret identifiers as numbers. Test names with accents, multiple surnames and non-Latin characters. Global programs need examples from several regions.

Recipient identity is one of the hardest parts of badge migration. Email addresses change, learners may have personal and work accounts, and duplicate accounts may already exist. Define matching rules that use more than one field when possible. Never merge two people only because their names match.

Clean the badge catalog before import. Duplicate templates, misspelled badge names and unused test badges can create confusion in the new system. Keep historical versions when they were actually issued. Remove only records that policy permits and document every exclusion.

When you migrate badges from one platform to another, preserve original issue dates. Reissuing every badge with the migration date can misrepresent the learner’s achievement and affect expiration rules.

Testing the destination platform

Create a representative test set. Include an active badge, expired badge, revoked badge, future-expiring badge, record with evidence, record without evidence, corrected name and recipient with a changed email address. Add badges with long criteria and special characters.

Import the test set and compare each field with the source. Check the administrator record, recipient view, public verification page and export from the destination. A dashboard value may be missing from the portable record.

Test status behavior using the guide to secure badge verification. Revoked badges should clearly show that status. Expired badges shouldn’t appear active. Evidence links should follow the intended privacy controls.

Check sharing destinations. Learners may use professional profiles, portfolios and email signatures. Existing guidance on LinkedIn digital badges and adding badges to email signatures can help define common tests.

Run a round-trip export from the new platform. Compare it with the imported data. That reveals which fields become proprietary, disappear or change format after migration.

Verification links and continuity

Old verification links may be embedded in resumes, profiles, websites and email signatures. Breaking them can damage learner trust even when the new records are accurate. Inventory link patterns and ask the source vendor how long pages remain available after closure.

The preferred option is a redirect from the old verification URL to the matching new record. That may require vendor cooperation or control over a custom domain. When redirects aren’t possible, keep a read-only verification archive for a defined period and notify learners that new links are available.

Avoid redirecting every old badge to a generic homepage. A verifier needs the specific credential record. If one-to-one redirects can’t be created, provide a lookup tool based on the original identifier or a clear support route.

The site’s article on sending digital badges is relevant because delivery and link continuity are connected. A migration communication should give learners a direct route to the new badge, explain what changed and state if action is required.

Document the long-term verification promise. Decide what happens if the new platform changes later. Stable issuer-controlled domains can reduce repeated disruption.

Recipient communication and support

Segment recipients according to action needed. Some learners may receive a new link automatically. Others may need to claim an account, update an email address or import a badge into a wallet. Don’t send the same message to every group when the steps differ.

Explain what remains unchanged. The achievement, original issue date and issuer authority should be clear. Also explain visible changes such as a new badge page, domain or sharing workflow. Avoid implying that the learner earned the credential again.

Give recipients a correction window before the old platform closes. Name and email problems are easier to resolve when staff can still inspect both systems. Provide a simple support form or email route and ask for the minimum information needed to locate the record.

Prepare answers for common questions: Is the old badge still valid? Why did the link change? Do I need a new account? Will my profile update automatically? Can I use the old image? Support teams should follow the migration policy.

How to migrate badges from one platform to another in phases

A phased rollout reduces risk. Start with a small badge family and a limited recipient group. Choose records that represent real complexity but don’t create severe consequences if the timeline slips. Monitor import errors, support volume and verification behavior.

Next, move a larger active cohort. Run old and new systems in parallel to compare status and recipient access. Freeze changes to the source catalog during the final migration window or record every change that must be replayed in the destination.

For the full cutover, create a reconciliation report. Count badge classes, issued badges, active records, expired records and revoked records in both systems. Investigate differences rather than assuming the destination count is correct. Duplicate imports can make totals look complete while data quality gets worse.

After cutover, keep a monitored exception queue. Some issues appear only when learners open old links or update profiles. Track root causes and fix mapping or communication problems rather than handling every ticket as an isolated case.

Security, privacy and audit requirements

Review the destination’s privacy configuration before import. Public badge pages should show only the fields intended for verification. Evidence may need restricted access. The article on GDPR and digital credentials can support privacy planning for European recipients.

Maintain an audit log of exports, transformations, imports, exclusions and corrections. Record who approved each step and when. That history supports incident review and explains why a destination record differs from the source.

Permissions need fresh review. Don’t copy every old administrator into the new platform automatically. Confirm current roles, remove inactive users and apply least-privilege access. A migration is a useful point to reset weak administration practices.

Post-migration checks and program improvement

Compare destination exports with the approved migration file. Confirm that later updates, revocations and expirations behave correctly. The new system must support ongoing lifecycle work, not only hold imported records.

Use the migration to improve operating rules. The guides to digital credential management software and enterprise credential integrations can help teams strengthen ownership and automation after cutover.

Retire the old platform only after the exit checklist is complete. Preserve contracts, exports, data dictionaries, mapping files and final reconciliation reports according to policy. Future administrators should understand where the records came from.

Frequently Asked Questions

Can you migrate badges from one platform to another without reissuing them?

Sometimes. A standards-based export or supported transfer may preserve original identifiers and metadata. Other destinations require reissuance from source records. The issuer should preserve original dates and explain any identifier change.

What happens to badges that were already shared?

Shared links may keep working, redirect or break, depending on the source platform and domain setup. Inventory old link patterns early. Learners should receive new links and a clear explanation before the old pages disappear.

Should revoked and expired badges be migrated?

Yes, when they form part of the issuer’s historical record or may still be presented to verifiers. Their status must remain visible. Omitting them can create gaps or allow outdated copies to appear valid.

How long should two badge platforms run in parallel?

Run them together long enough to validate data, resolve recipient issues and confirm link continuity. The right period depends on program risk and vendor contract terms. Define exit criteria rather than choosing a date alone.

Final Thoughts

A careful plan to migrate badges from one platform to another protects more than data. It protects the learner’s proof, the issuer’s reputation and the verifier’s ability to trust the record. Inventory, field mapping, testing and reconciliation should happen before the old system closes. Communication and link continuity deserve the same attention as imports. Digitalcredentialplatforms.com provides related resources on badge management, verification and platform integrations for teams preparing a safer transition.