When an organisation switches Peppol provider, the SMP registrations need to be transferred. During the switch the Participant ID stays registered, so senders can keep sending. The PSB offers two migration scenarios via the API.

No migration key without a receiving registration: if the party has no active Peppol receiving registration via eConnect (no SMP claim for receiving), there is nothing to migrate and prepareToMigrate is not needed. Register receiving directly with the new provider. Send-only while an SMP claim is still at eConnect is not the same as "no receiving registration" — the claim stays claimed and the migration-key route is still required to release it.

If a party moves from eConnect to another Peppol Access Point provider, you prepare the migration via the prepareToMigrate endpoint:

GET /api/v1/peppol/{partyId}/prepareToMigrate

This endpoint does two things:

1. It marks the party in the eConnect SMP as "in migration"
2. It registers a migration key with the Peppol SML

The API returns the migration key in the response. Pass this key to the new provider, who needs it to take over the registration in their SMP.

{
  "migrationKey": "abc123-def456-ghi789"
}

After completion, the Service Group at the eConnect SMP is removed, possibly with a temporary redirect to avoid an interruption.

If a party moves to eConnect from another Peppol Access Point provider, you need the migration key that the current provider has generated. Add this key to the party configuration via:

PUT /api/v1/peppol/config/party/{partyId}

With the migration object in the request body:

{
  "migration": {
    "key": "the-migration-key-from-the-current-provider"
  }
}

The PSB completes the migration automatically: the SMP registration is taken over and the SML is updated. From that point on, all Peppol messages for this party are routed through the eConnect Access Point.

If the migration key is invalid or expired, the migration fails and the API returns an error message. In that case, request a new key from the current provider.

Non-API route (platform customers): start in the platform via My environment → Cancel account → Migrate. A loose support request is not the customer route. Without portal access, support starts the cancellation form. After the form, financial clearance and processing by superadmin support, you receive the migration code in a secure email from TechSupport, not in a ticket or announcement email. Pass that code only to the new provider. Two conditions apply: (a) the customer gives eConnect a written/legal instruction, and (b) the customer has no outstanding financial obligations with eConnect. The steps below describe the API-equivalent procedure.

Intermediary/bulk without Administrator role: an intermediary with only an authorisation (no Administrator role) on customer organisations usually cannot start a self-service cancellation/migration for those orgs themselves. For a bulk switch of multiple customer orgs/environments, this goes through support (one migration key per Peppol ID) — not via revoking connection keys. Revoking connection keys only breaks the API link and is not an SMP deregistration.

Number of keys for bulk requests: the number of unique migration keys can be lower than the number of organisations in the request — only orgs with an active receiving registration get a key. Multiple emails with the same unique keys together form a complete delivery once all Peppol IDs to be migrated are covered.

1. The party decides to switch to another provider
2. Call GET /api/v1/peppol/{partyId}/prepareToMigrate
3. Pass the migration key to the new provider
4. The new provider takes over the SMP registration using the key
5. The registration at eConnect is automatically cleaned up

1. The party decides to switch to eConnect
2. The current provider generates a migration key
3. Call PUT /api/v1/peppol/config/party/{partyId} with the migration key
4. The PSB takes over the SMP registration and updates the SML
5. Then configure the desired capabilities and hooks

During the switch the party stays registered in the network, so senders can keep sending. Invoices are caught at the old and the new Access Point so the invoice flow does not stop. Which point a message reaches depends on the timing of the SML update (DNS). A standard migration usually takes several working days. eConnect guides that process at no charge.

After a successful migration to eConnect, the SML updates the DNS records. Do not assume every lookup already points to the eConnect Access Point at the same moment. After the migration, always configure the capabilities and set up the required hooks.

Don't forget to set up user permissions and optionally a businessCard via the Enrollment API if that hasn't been done yet.

Need help with a migration? Contact TechSupport for guidance on the migration process.