I spent 14 years at Qlik. I started as a consultant, and by the time I left I was running Global Delivery Services across five continents. In that time, I was in more migration projects than I can accurately count — some successful, some deeply painful, and a few that were outright disasters.
The disasters taught me more.
Here's what I know now that I wish every client had been told before signing the migration SOW.
The Vendor Will Not Tell You What You're About to Step Into
Let's start there. The sales team has closed the deal. The new platform is licensed. The kick-off is scheduled. Everyone is enthusiastic. And nobody — not the vendor, not the implementation partner, not the internal champion — has any real incentive to stop and say, "Before we move anything, let's find out exactly what we have."
That conversation slows things down. It raises uncomfortable questions. It might surface a scope that nobody budgeted for.
So it doesn't happen.
What happens instead is a migration kicks off against an assumption. The assumption is that the environment is roughly what it looks like on the surface. And the environment is never what it looks like on the surface.
The Real Problem Is Never the Technology
I've seen migrations blamed on poor tooling, bad platform choices, vendor support failures, timeline pressure. Those things happen. But in my experience, the technology is almost never the root cause of a failed migration. The root cause is almost always one of three things: sprawl, undocumented dependencies, or tribal knowledge that walked out the door.
Sprawl is what happens when an analytics platform succeeds. Developers multiply. Departments get access. Everyone builds their own version of the same report. Nobody decommissions anything because they're not sure if someone still uses it. Five years in, you have an environment that's three times larger than it needs to be, and a meaningful portion of it is either redundant, obsolete, or was never worth building in the first place. I've walked into environments where 40% of the app inventory hadn't been opened in over 12 months. That's not a portfolio — that's a graveyard with a license fee attached.
Undocumented dependencies are the silent migration killer. Analytics apps don't exist in isolation. They share data connections. They reference common scripts. They feed downstream reports that feed other downstream reports. A dependency map, in most organizations I visited, either didn't exist or was wildly out of date. You'd migrate an app, it would pass every check you ran on it, and two weeks later someone would call because their entirely separate dashboard was now broken. Because nobody knew the two were connected.
Tribal knowledge is the one that keeps me up at night. The person who built the core data model left 18 months ago. The team that maintained the production environment handed it off in a two-hour knowledge transfer. The business rules behind a key calculation live in one analyst's head, and she's been promoted into a role where she no longer touches the data. When migration questions surface — why is this field calculated this way? what is this script actually doing? — the answer is "we think it was always like that." That is not an answer. That is a time bomb.
Lift and Shift Is a Fantasy
I heard "lift and shift" constantly from clients. They wanted it to be true. It's simpler. It's faster to say. It gives the project a kind of mechanical inevitability — we just pick everything up and put it somewhere new, and it works.
It never works. Not in analytics. Not for environments of any real complexity.
Here's why: an analytics app isn't just code. It's a set of assumptions about data structures, connection behavior, calculation logic, and rendering. When you move it to a new platform — even from one version of the same vendor's product to another — those assumptions get tested. Some of them fail. Others produce subtly wrong results that pass every visual check and only get caught six months later when a finance director asks why her quarterly numbers don't match the board deck.
What "lift and shift" actually delivers, in practice, is a migration that looks done while still carrying all the debt of the original environment. The scripts are there. The apps open. The data loads. But the logic hasn't been reviewed, the redundancy hasn't been addressed, and the tribal knowledge problems have just been transplanted into a new system.
You haven't modernized anything. You've moved the mess.
Cleaning Up Before You Migrate Is the Highest-ROI Work You Can Do
This is the thing clients almost never want to hear, but I've watched it play out enough times that I'll say it plainly: the most valuable thing you can do before starting a migration is reduce what you're migrating.
Every app you eliminate from scope before the migration starts saves you in at least four ways:
- You don't pay to migrate it.
- You don't pay to validate it.
- You don't pay to support it on the new platform.
- You don't carry its technical debt into the new environment.
I've seen diagnostic work cut migration scope by 30 to 40 percent. That's not a rounding error. That's the difference between an 18-month project and a 10-month project. That's the difference between a budget that holds and one that gets re-forecast twice before anyone writes a post-mortem.
The objection I always heard was: "We don't have time for that upfront work. We need to move." And every time — without exception — the organizations that skipped the diagnostic spent more time on the migration than they would have spent on the diagnostic plus a leaner migration. Every time.
What I Actually Saw Across Global Enterprises
Across every continent, every industry vertical, every scale of organization, certain patterns repeated with enough consistency that I stopped being surprised by them.
The "we'll clean that up after we migrate" promise. It never happened. Once an environment is running on the new platform, the pressure shifts to adoption, to new development, to whatever the next initiative is. The cleanup that was deferred pre-migration gets deferred again post-migration, and the debt compounds.
The incomplete inventory. Organizations would hand us a list of apps to migrate. We'd run our own discovery. The number was almost always significantly higher. Shadow IT, departmental instances, development environments that had quietly become production — these showed up constantly. You cannot plan a migration against an incomplete inventory. You will be surprised, and surprises in migration projects are expensive.
The "no one owns this" app. There's always a cluster of apps — sometimes a large one — where the question of ownership produces silence. They were built by someone who left, or inherited through a reorganization, or created for a project that wrapped two years ago. Nobody wants to migrate them because nobody wants to be responsible for them on the new side. But nobody wants to decommission them either, because they're not sure someone isn't using them. These apps are paralysis generators. The right answer is almost always to decommission them after checking usage data. But it takes discipline to make that call.
Migrating R.O.T. at full price. Redundant, Obsolete, Trivial content — R.O.T. — gets migrated because it's easier than making decisions. The consulting engagement is scoped by app count. Nobody is incentivized to shrink the scope. So 40 apps that collectively serve three occasional users get the same treatment as the 10 apps that run the business. The budget gets consumed on content that should never have survived the diagnostic.
The Conversation Worth Having Before You Sign Anything
If you're heading into a migration — any migration — here are the questions I'd insist on having answered before the scope is set:
What does our analytics inventory actually contain? Not what you think it contains. Not what the spreadsheet from three years ago says. What is actually deployed, what is it connected to, and when was it last used.
What percentage of that inventory qualifies as R.O.T.? If you don't have a diagnostic framework to answer this question, get one before you write a check.
Where are our undocumented dependencies? Map them. Not because it's theoretically good practice, but because your migration will break things along those dependency chains if you don't.
What tribal knowledge exists and where is it documented? If the answer is "it mostly lives with a few people," that is a migration risk, not a comfortable assumption.
What is the actual cost of migrating versus decommissioning each subset of content? This is a decision, not a default. Treating every app as equally worth migrating is how you migrate your way into a new version of the same problem you already have.
The Migration Is Not the Outcome
This is maybe the most important thing I can say from 14 years of watching these projects land.
The migration is not the goal. A clean, governed, trusted analytics environment on a modern platform — that is the goal. The migration is a means to get there, and it will only get you there if the work done before and during the migration was disciplined enough to eliminate the problems you already had rather than just relocate them.
The organizations that treated migration as a technical exercise — move the apps, check the boxes, call it done — invariably found themselves back in the same conversation 18 months later. Different platform, same sprawl, same dependency confusion, same tribal knowledge gaps. The organizations that treated migration as a chance to rationalize, govern, and simplify their analytics estate came out the other side with something actually worth having.
The difference was almost never technical capability. It was almost always the willingness to do the diagnostic work first.