2-M Logo2-M
Switch to French

Migrating to Fabric

Migrating is not rebuilding. It is recovering what your system already knows.

The difficulty of a reporting migration is never moving the data. It is the business logic accumulated over the years, which nobody has documented anywhere other than inside the tool.

0

hard cutovers. The new chain runs in parallel until the figures agree.

Reconciliation period by period before anything moves

The sequence

One domain at a time, alongside what you already run

  1. Inventory

    Sources fed, transformations in place, reports that depend on them.

  2. First domain

    Usually sales: the scope where any gap shows up immediately.

  3. Comparison

    Your teams put the two platforms side by side on their own figures.

  4. Gradual cutover

    Domain by domain, at the pace the facts justify.

Where you start from

Four starting points, four different difficulties

Migration situations towards Fabric
What you runWhat carries overThe real difficulty
TimeXtenderThe structure of the warehouse, the tables and the data movements are explicit and can be read back.The business logic lives in the project and often nowhere else. It has to be extracted before it can be rebuilt.
Jet AnalyticsThe pre-packaged models for Microsoft ERPs give a readable starting base.The customisations added over the years, which depart from the standard without being documented.
On-premises SQL Server warehouseThe stored procedures and the views describe the transformations precisely.The scheduling and the implicit dependencies between jobs, rarely written down anywhere.
Power BI aloneThe semantic model is reused as it is: that work is not lost.The rules recoded in every report, which diverge from one another and have to be arbitrated.

How we proceed

Nothing moves until the figures agree

  1. Archaeology of the existing logic

    We read the project in place and extract its business rules, one by one. It is the most thankless and the most decisive phase: whatever is not found now will be discovered by a user six months after the cutover.

  2. Arbitrating the diverging rules

    A migration brings accumulated contradictions into the open: two definitions of the same measure, two scopes for the same indicator. Those decisions belong to your business teams, not to us. We document them and have them settled.

  3. Building in parallel

    The new chain is built while the old one keeps running. No interruption, and above all no calendar pressure pushing a cutover before anyone is ready.

  4. Reconciliation period by period

    We compare the results of the two chains until they agree. Every gap is explained: either it is a bug in the new one, or it is a bug in the old one that nobody had seen. Both happen.

  5. Cutover and retirement

    Once the figures agree and that agreement is accepted, the old chain is switched off, not before. The cost of running it a few weeks longer is trivial beside the cost of a failed cutover.

When not to migrate

A warehouse that works deserves to be kept

We sell migrations, and we regularly advise against them. A newer platform is not a sufficient reason.

If your current warehouse produces correct figures, your users are satisfied with it and its maintenance cost is under control, migrating will cost you a project to arrive at the same result. A migration is justified when what you run blocks something: a real-time need, a volume that no longer passes, a skill that has become impossible to hire, a vendor changing its terms.

Frequently asked

What people ask about migrations

Does everything have to be rebuilt to migrate to Fabric?

No, and that would be the worst way to go about it. An existing semantic model is reused, the measures are carried over, and the reports in place keep working. What changes is what sits upstream: where your data was prepared, and by which tool. The migration is about that layer, not about the reporting.

Can we migrate from TimeXtender or Jet Analytics?

Yes, and it is ground we know from the inside: we have been integrating those tools for years. The difficulty is not technical but documentary, because the business logic accumulated in a TimeXtender project often exists nowhere else. So the migration starts by extracting that logic before rebuilding it, otherwise years of business rules are lost.

How long does a migration take?

It depends far less on the volume of data than on the number of business rules to carry over. A simple warehouse with a few dozen transformations migrates in weeks. A project accumulated over ten years, parts of which nobody understands any more, calls for an archaeology phase that should not be underestimated.

What happens to our existing platform during the migration?

It keeps running. We build the new chain in parallel and compare the results of the two, period by period, until they agree. The cutover only happens once that reconciliation is done. Nobody should accept a hard cutover on a reporting system.

And if we decide not to migrate?

That is a perfectly legitimate decision, and we will say so if we judge it reasonable. A warehouse that works, whose users are satisfied and whose maintenance cost is under control, does not need replacing. A migration is justified when the existing platform blocks something, not because a newer one exists.

The method

One domain at a time

Each domain moves across one after the other while the existing platform keeps serving. The overlap lets your teams compare the two platforms on their own figures before deciding what comes next.

Two hours to find out what your existing platform really contains.

Eleven expert consultantsSaint-Priest, near Lyon, France

A scoping workshop with a consultant, free and without commitment. We look at the project in place, estimate how much logic has to be carried over, and tell you straight whether the migration is justified.

Request a scoping workshop

Scoping workshop · 2 hours · free

Our technologies

Microsoft FabricPower BIPower AppsPower AutomateMicrosoft Partner