BI and data platform migration
BI platform migration moves reporting and data infrastructure to a new platform without interrupting the reporting the business runs on. Kodelytics leads Tableau Server to Tableau Cloud migrations, warehouse-to-warehouse moves, and CI/CD programs for managed Postgres — owning inventory, dependency mapping, sequencing, and phased cutover.
Migrations rarely fail on technology. They fail on inventory: nobody knows how many workbooks exist, which ones anyone opens, what they depend on, or who owns them. Work starts on the visible reports, the deadline arrives, and the last twenty percent turns out to contain the ones the executive team uses. The technical execution is often the easiest part of the program.
Which is why the inventory phase is worth buying on its own. Two weeks of counting produces a defensible scope, a rationalization list, and an estimate that isn't fiction. Programs that skip it are estimating against a number nobody has verified, and the variance is routinely a factor of two.
A phased cutover moves a platform in defined tranches, each with written entry and exit criteria, running old and new in parallel until a tranche is validated. The alternative — a single switch date — concentrates all discovered problems into the one window where there is no fallback.
What's actually wrong
These are the symptoms buyers of this service recognize before they can name the problem.
- The number of data sources and workbooks in scope is an estimate, not a count.
- Nobody can say which reports are actually used, or by whom.
- A vendor end-of-life or licence renewal date is driving the timeline.
- The migration team is technically strong and has never run a migration.
- Client IT, a partner consultancy, and internal developers each hold part of the plan.
- There's no defined test for whether a migrated report is correct.
What the engagement includes
- Full inventory of data sources, workbooks, extracts, schedules, and permissions, with usage data attached.
- Dependency mapping — what feeds what, and what breaks if it moves.
- Rationalization: the reports not worth migrating, identified before effort is spent on them.
- A phased cutover plan with per-phase entry and exit criteria.
- Assignment tracking across developers and partner firms, with a single visible source of status.
- Validation methodology: how a migrated report is proven equivalent to the original.
- Stakeholder coordination across client IT, security, partner consultancies, and business owners.
- CI/CD design for managed Postgres and database change management where the migration includes the data layer.
- Client-facing process documentation stakeholders use to approve each phase.
- Post-cutover support window and decommissioning plan for the legacy platform.
Rationalization: the cheapest work in the program
Every mature BI deployment contains reports nobody opens. Usage data plus a named owner resolves them: a workbook with no views in twelve months and no owner willing to claim it is archived with a documented decision rather than migrated.
This routinely removes a material share of scope, and it is the only phase where the deliverable is less work. It requires air cover, because someone always objects on principle to archiving a report they do not use.
Coordinating three organizations
These programs typically involve the client's IT function, a partner consultancy executing conversions, and internal business owners approving results. Each holds part of the plan, and the default failure is three partial plans and no shared status.
Kodelytics consolidates the channel: one tracker every party reads, one point of contact for the client's IT director, one validation standard applied to every asset, and process documentation stakeholders use to approve each phase. Conversion work stays with the developers who do it; sequencing, tracking, validation, and coordination are what the engagement owns — and the case notes on this site name that division explicitly.
Where migration programs actually fail
| Phase | Assumed risk | Real risk |
|---|---|---|
| Inventory | Low | Highest — unknown scope |
| Conversion | Highest | Moderate and estimable |
| Validation | Low | High — no agreed definition of correct |
| Access and provisioning | Trivial | Chronic schedule risk |
| Decommissioning | Ignored | Licence cost and shadow usage |
How it's scoped and priced
Scoped as a fixed-fee or banded-hours SOW after an inventory phase, because an estimate produced before the inventory exists is a guess. The inventory itself can be a short standalone engagement — often the most valuable two weeks of the program.
Kodelytics acts as delivery lead rather than sole implementer: your developers or a partner consultancy execute conversions, while Kodelytics owns sequencing, tracking, validation, and the coordination between parties. Where developers are needed, they're named individuals introduced to you and scoped separately.
Kodelytics does not publish rates. Every engagement is quoted after a discovery call, because the same service name covers materially different amounts of work.Ask for a quote.
What you get at the end
- A complete inventory with usage and ownership per asset.
- A dependency map.
- A phased cutover plan with entry and exit criteria.
- An assignment tracker covering every asset and owner.
- A validation record per migrated asset.
- Process documentation for stakeholder approval, and a legacy decommissioning plan.
Questions
How long does a Tableau Server to Tableau Cloud migration take?
For a mid-size deployment — on the order of 150 data sources and 100-plus workbooks — plan on three to six months end to end, with inventory and rationalization in the first weeks and a phased cutover after. The variable is rarely conversion effort; it's stakeholder validation and access provisioning.
Do you do the migration yourselves?
Kodelytics leads delivery: inventory, sequencing, tracking, validation, and coordination. Conversion work is executed by your developers or a partner consultancy. That division is stated up front in the SOW, and named in the case notes on this site.
How do you decide what not to migrate?
Usage data plus a named owner. A workbook nobody has opened in a year with no owner willing to claim it does not get migrated; it gets archived with a documented decision. Rationalization routinely removes a material share of the scope.
What is CI/CD for a managed database?
Version-controlled schema changes deployed through an automated pipeline with review, testing, and rollback — instead of applied by hand in a console. On Azure Database for PostgreSQL that means migration scripts in source control, pipeline-run deployments, and an auditable change history.
Who talks to the client's IT department?
Kodelytics, as the single point of contact. Consolidating that channel is usually the reason these programs stay on schedule.