Skip to content
English - United Kingdom
Contact us
  • There are no suggestions because the search field is empty.

Merging integration instances

When you consolidate two integration instances into one — for example merging two Bullhorn instances after an acquisition — plan for two separate side effects: users may end up duplicated if their email address changes between instances, and billings from the instance being decommissioned can be left "orphaned," with no source system left to confirm them. Handling both before and after the migration keeps your statements clean.

Before the migration: check for email changes

The most common cause of duplicate users during a merge is a change of email address between the old instance and the retained one. Before you migrate:

  1. Confirm whether your users will keep the same email address on the retained instance. If so, no action is needed — Konquest will keep matching billings to their existing user as normal.
  2. Where a user's email will change, add the new address as an email alias on their existing Konquest user ahead of the migration. See Using email aliases to prevent duplicate users for the exact steps.

Adding aliases ahead of time is the simplest way to avoid dealing with any duplicates at all once the migration is live. If a duplicate does slip through anyway, the same article covers how to retain the correct user and add the duplicate's email as an alias afterwards.

After the migration: watch for orphaned billings

Merging two instances typically means the same placement or deal exists in both systems for a period — one copy synced from the instance being decommissioned, one from the instance you're keeping. Konquest will usually end up holding two distinct billings for the same underlying work, each tracking its own source.

Once the old instance is switched off, its billings stop receiving any further status updates from source — there's nothing left to sync from. If one of those still needs a status change to become confirmed (for example, moving to an "Invoiced" or "Placed" status), it never will, because there's no source system left to drive that change. That billing is effectively orphaned: it will sit unconfirmed indefinitely unless someone deals with it manually.

To clear this up:

  1. Once the migration is complete and the retained instance is confirmed to be syncing correctly, go through the placements that originated from the decommissioned instance.
  2. Cancel the ones that duplicate a placement now being tracked from the retained instance, leaving just the version synced from the instance you kept.

This is a deliberate clean-up step, not routine housekeeping — check each placement is genuinely a duplicate of one now coming from the retained instance before cancelling it. Cancelling a placement that's already contributed to an approved statement can affect that statement, so if you're not sure whether a specific placement has already been paid out on, check before cancelling rather than after.

Using Konquest's MCP tools for this

If you or your team use Claude or Copilot, the Konquest MCP server can help you work through a batch of users and placements for a migration like this much faster than doing it by hand in the UI — for example, checking which users already share an alias, or listing placements from a specific integration to review before cancelling. See the MCP setup guides for Claude and Copilot to get started.

Need help?

If you're planning a migration and want a hand identifying which users need aliases, or reviewing placements for orphaned billings once it's done, contact your Konquest support contact — we're happy to assist at any stage of the process.