Keeping Client Integrations Alive During a System Migration (An MSP Perspective)

[Diana_Architect_ZigiWave]

Hey everyone,

If you are working at an MSP and you have been through a few client system migrations, you already know the drill. The data migration gets all the attention. The integrations? They get remembered at the worst possible moment - usually when something breaks at 11pm the night of cutover.

This post is not a sales pitch and it is not a formal guide. It is a practical look at what tends to go wrong with integrations during system migrations - and what MSP teams can do about it before things break. Some of it is obvious in hindsight. Not much of it feels obvious when you are in the middle of a client cutover.

If any of it is useful, great. If your team has done things differently and it worked better, share it in the comments - that is genuinely why these posts are worth writing.

The thing about integrations that makes migrations harder

When you migrate a client from one system to another - say, from a legacy project tool to Jira,  you are not just moving data. You are changing the foundation that a bunch of connected workflows are standing on.

Integrations are built on assumptions. Field names. API endpoints. Authentication tokens. Data schemas. The moment one of those changes, any integration that relied on it is either broken or producing garbage data - and it might take a while before anyone notices.

For an internal IT team, this is painful. For an MSP managing ten clients at once, it is a recurring operational headache that scales with every new engagement.

The failure modes are pretty consistent across clients:

• Field names change. Something called 'Priority' in the old system maps to a completely different field in the new one, with different values and different logic behind it. The integration keeps running and keeps pushing data - just the wrong data.
• API endpoints shift. New platform versions expose different endpoints. Hard-coded connections stop working silently or start throwing errors that nobody catches until a workflow breaks.
• Credentials expire or need reissuing. OAuth tokens, API keys, and service accounts all need to be set up fresh in the new environment. This one gets missed more often than you would expect, especially on migrations that are moving fast.
• Timing creates duplicates. During phased migrations, records exist in both the old and new system at the same time. Without proper conflict handling, you end up with duplicate tickets, duplicate alerts, or updates that write to the wrong place.

None of these are exotic problems. They are all predictable. The issue is that under migration pressure, predictable problems still get overlooked.

What to sort out before the migration starts

The single most useful shift is treating the integration audit as part of the migration scoping - not something to get to later.

Before any client migration kicks off, it helps to have clear answers to:

• What integrations are currently running in this environment
• What data they are moving and how often
• Who built them and whether anyone still understands them
• What breaks immediately if they go down, and what can wait

That last question is the important one. Not all integrations are equal. Some are holding up incident response workflows - those need to stay live throughout the entire migration. Others are feeding weekly reports that nobody would notice were broken for 48 hours. Treating them the same way wastes effort and creates unnecessary risk.

A simple three-tier approach works well here: mission critical, business important, and everything else. It is not a sophisticated framework. It just forces the conversation about priorities before the migration window opens rather than during it.

The other thing worth doing early is mapping dependency chains. In Atlassian environments especially, Jira is often in the middle of a chain: a monitoring alert fires, creates a ServiceNow incident, which triggers a Jira ticket, which sends a notification somewhere. If you migrate Jira without thinking about what is upstream and downstream, you can break workflows that have nothing obviously to do with Jira.

During the migration: the dual-system problem

Phased migrations are generally the right approach for enterprise clients - lower risk, more control, easier rollback. But they create a specific integration challenge: for a period of weeks or months, some data lives in the old system and some lives in the new one. Your integrations need to handle both.

There are two approaches that work reasonably well depending on the situation.

• Dual-write means configuring integrations to write updates to both systems simultaneously during the migration window. Both environments stay consistent regardless of which one a user or process is currently working in. It requires a bit more setup - you need conflict resolution logic and deduplication to handle cases where updates arrive from both systems at the same time - but it gives you a clean rollback option if something goes wrong in the new environment.
• Read-from-source, write-to-target is simpler and works well when the migration is mostly one-directional. Integrations keep reading from the old system while pushing everything to the new one. Good for Jira migrations where you are winding down an old instance over a defined window.

Either way, the key thing is having this conversation before migration day - not improvising it at 2am when users are complaining that their tickets are not syncing.

One more thing on rollbacks: every Tier 1 integration needs a documented rollback path. Not a general plan - a specific one. If the new environment fails and you need to revert, how long does it take to get that integration pointing back at the source system? If the answer is 'rebuild from scratch,' that is a problem worth solving before cutover.

The data migration and integration split that causes problems

A common pattern in MSP engagements: the data migration workstream and the integration workstream get handed to different people and managed as separate tracks.

This creates a specific problem. When the data migration team normalizes field values, merges duplicate records, or updates naming conventions, those changes need to be reflected in the live integration configuration at the same time. If they are not, the integration starts pushing data in the old format into a system that now expects the new format. Sync errors, data corruption, confused users.

The fix is not complicated - it is just a coordination habit. Whoever is making data migration decisions needs to be in the same conversation as whoever is managing the integration configuration. In Jira environments this often means the person handling the project data migration needs to stay in sync with whoever is managing the Jira integrations - whichever platform you are using.

On tooling: what actually helps

There is no single right tool for this. There are several capable integration platforms, and the right choice depends on the client's existing stack, your team's familiarity, and what you are connecting.

The tooling decisions that tend to matter most during a migration are:

• How quickly can you update a configuration when something changes? Migration plans change. Field names get finalized late. Cutover dates shift. If updating an integration requires a developer and a change management ticket, you are going to be slow when you need to be fast. Tools that let any qualified engineer make configuration changes from a UI - without writing code - are meaningfully better for migration scenarios.
• Can you monitor integration health in real time? During a migration window you want to know immediately when something starts failing - not when a client calls to ask why their tickets are not syncing. Real-time dashboards and alerting matter a lot more during migrations than during steady-state operation.
• Does the platform store client data? Worth checking. Some integration platforms retain data in transit in their own databases. For MSPs handling client data under GDPR or other compliance frameworks, this is a question your clients' security teams will ask. Platforms that transfer data without storing it simplify that conversation considerably.
• Can it handle bidirectional sync with conflict resolution? Especially important for phased migrations where both systems are live simultaneously.

One platform worth knowing about in this context is ZigiOps - a standalone, 100% code-free integration platform that does not store client data and lets engineers update configurations directly from the UI. It ticks most of the boxes above and works well in multi-client MSP environments. That said, there are other capable options depending on your stack - the criteria above are what matter, not the specific tool.

The Atlassian Migration Support is a solid starting point if you are planning a Jira or Confluence migration and want to understand the official recommendations before you start thinking about the integration layer.

A few things worth putting on your pre-migration checklist

These are the items that consistently prevent post-migration incidents when they are handled early - and consistently cause them when they are not:

• Document every active integration with its owner, data flow, and authentication method before migration planning starts
• Classify integrations by criticality and get client sign-off on which ones need zero downtime
• Map dependency chains across connected systems so you understand what is upstream and downstream of everything being migrated
• Set up and test new integration configurations in a staging environment before the migration window opens - with realistic data volumes, not just a smoke test
• Validate service account permissions in the new environment explicitly - do not assume they carried over
• Define rollback procedures for Tier 1 integrations before cutover day
• Communicate integration changes to client stakeholders in advance - they need to know what to watch for, not just that a migration is happening

None of this is groundbreaking. But the items that get skipped under time pressure are almost always on this list.

Wrapping up

System migrations are genuinely complex, and the integration layer is where a lot of that complexity hides until the worst possible moment. For MSPs managing multiple client environments, the stakes are higher because every migration is somebody's critical business process.

The good news is that integration failures during migration are largely predictable and largely preventable. The patterns repeat across clients, across tools, and across migration types. The more migrations you run with a structured approach to the integration layer, the more that institutional knowledge compounds into faster, cleaner delivery.

If you are currently working through a Jira or Atlassian migration and dealing with integration challenges, drop a comment below. Happy to compare notes.

Explore how ZigiOps connects Jira with other enterprise tools if you want to see what a no-code integration setup looks like for common Atlassian use cases.