Leaving a MicroStrategy project
We read the metadata before we draw a chart: attributes, facts and hierarchies become a star-schema semantic model, the lookup-table snowflake is flattened, Level Metrics are rewritten as named DAX measures, security filters become row-level security, and every rebuilt number is reconciled against its original report.
Representative dashboard — sample data
Where the work really is
This is not a generic legacy-reporting rebuild, and it is not the spreadsheet route. Teams whose numbers still start life in Excel workbooks belong on our Excel-to-Power BI migration service; what makes MicroStrategy different is that a governed semantic layer already exists, and it is the thing you are actually moving. Attributes with their forms, facts at several levels, parent-child hierarchies resolved through normalised lookup tables, metrics carrying their own dimensionality, transformations that shift a time comparison, security filters that quietly decide who sees which rows.
Every one of those is a definition someone agreed to years ago, and none of them import. So the honest framing is that the migration is a semantic-layer rebuild with a reporting deliverable on the end of it. Get the attributes, the grain and the Level Metrics right and the reports follow quickly. Copy the dossiers first and you inherit the same ambiguity in a new tool, without the run-time SQL generation that was quietly rescuing you.
What the rebuild covers
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Documenting one project area and the reports that depend on it makes a good first task: it tells you the real size of the job before you commit a budget to it.
How we approach it
The MicroStrategy SQL Engine does a lot of work at run time that Power BI expects you to have settled in the model. Naming those behaviours early is what keeps the rebuild predictable instead of surprising you at month-end.
We walk the project metadata before any visual is drawn: attributes and their ID and description forms, attribute relationships, facts and the tables that hold them, hierarchies, transformations, and the partition or aggregate tables behind them.
Chains of normalised lookup tables — item to subcategory to category to division — collapse into one conformed dimension per business entity, so relationships stay short and measures stay readable.
Dimensionality that lived in a metric's target, grouping and filtering settings is rewritten as filter context you can read: percent-of-parent, share-of-total and ignore-the-report-filter behaviour, each as a named measure.
Last year, last month and prior period transformations are re-expressed against a marked date table using standard DAX time-intelligence patterns, which makes fiscal calendars and 4-4-5 periods an explicit decision rather than a metadata side effect.
Attribute qualifications that restrict a user's rows, along with any connection mapping doing the same job at the database, are re-expressed as a security table plus a row-level security role, then tested user by user.
Statements, remittances and board packs are not dashboards. Anything that came out of a Report Services Document for printing or bursting is rebuilt as a paginated report so page breaks and every printed row land where the recipient expects them.
MicroStrategy separates schema objects from application objects. Schema objects — attributes, facts, hierarchies, transformations and the logical tables behind them — describe your warehouse to the SQL Engine, which assembles a query at run time by choosing tables and joins for you. Application objects — metrics, filters, prompts, templates, reports, documents and dossiers — consume that description. Power BI splits the same responsibility differently: a semantic model holds tables, relationships and DAX measures, and reports visualise it. The migration is therefore a model rebuild with a known map, not a file conversion.
The practical consequence is where ambiguity gets resolved. MicroStrategy can map one fact to several tables at different levels and pick the cheapest at query time; a tabular model has no equivalent rescue, so the grain has to be right in the table or the measure is wrong everywhere it is used. That is a relocation of the decision rather than a drawback, and it is the reason we read the schema before quoting the reports.
Estates differ mostly in how much of the logic sits in the metadata versus the warehouse. A project fed by a well-formed dimensional warehouse translates quickly, because the star is already there and the schema objects mostly describe it. A project that grew by accretion — attributes defined on operational tables, facts with expressions, custom SQL in freeform reports — needs the extra step of deciding what belongs in the warehouse, what belongs in Power Query, and what belongs in a measure.
This is the working map the plan is built from. It is deliberately unglamorous: the value of a migration map is that nothing surprising appears in week three, and that every line has an owner who agreed to it.
| MicroStrategy object | Power BI equivalent | What changes in practice |
|---|---|---|
| Attribute with ID and description forms | Dimension table with a key column and descriptive columns | Forms become ordinary columns; sort-by-column replaces the display-form setting |
| Attribute relationships and lookup tables | One flattened dimension table per business entity | The normalised snowflake collapses; join chains stop being resolved at query time |
| User hierarchy / system hierarchy | Model hierarchy on a dimension table | Levels survive; the drill path is rebuilt on the visual rather than declared in metadata |
| Fact mapped to several fact tables | One fact table at one grain, sourced by a single query | Table selection stops happening at run time and becomes a modelling decision |
| Aggregate tables and partition mapping | A base-grain fact, or user-defined aggregations in the model | The performance trick becomes explicit and testable instead of implicit |
| Simple metric on a fact | A named DAX measure using SUM or a base aggregation | Definitions move from the metadata into readable, version-controlled expressions |
| Level Metric with target, grouping and filtering | CALCULATE with REMOVEFILTERS, ALLEXCEPT or VALUES | Dimensionality settings become filter context you can read, test and reuse |
| Compound and smart metric | A measure written to evaluate at the intended grain | Aggregate-then-divide versus divide-then-aggregate becomes an explicit choice |
| Transformation (last year, prior period) | Time-intelligence DAX over a marked date table | Fiscal calendars and 4-4-5 periods are declared once in the date dimension |
| Consolidation | Grouping column on a dimension, or a calculation group | Ad-hoc element groupings become maintained data instead of report-local logic |
| Custom group with banding | Banding column, or a disconnected band table with a measure | Band definitions become visible in the model and stop drifting between reports |
| Filter object reused across reports | Report filter, a boolean model column, or a calculation-group item | Shared filters are rebuilt once and referenced, not copied per report |
| Prompt (attribute element, value, object) | Slicer, field parameter, or what-if parameter | Users change the view themselves instead of re-answering a prompt each run |
| Security filter on a user or group | Row-level security role with a DAX filter | Row rules move onto the model and are verified with the View as role feature |
| Connection mapping to a database user | Gateway data source plus row-level security | Database-level impersonation becomes a model-level rule you can test |
| Object and folder ACLs | Workspace roles and app audiences | Who sees which content becomes a permissions question, not a modelling one |
| Grid or grid-graph report | Report page with matrix, table and chart visuals | Each report stops carrying its own definition and reads from one governed model |
| Dossier with chapters and pages | Power BI report with pages, bookmarks and sync slicers | Navigation is rebuilt rather than translated; filter panels become slicers |
| Report Services Document and bursting | Paginated report in Power BI Report Builder, plus subscriptions | Layout and per-recipient delivery are preserved rather than approximated |
| Intelligent Cube | Import-mode semantic model with scheduled refresh | An in-memory cube people published to becomes the shared model itself |
| Freeform SQL or Query Builder report | Power Query native query, or a view in the warehouse | Hand-written SQL is reviewed and usually promoted into the warehouse |
| VLDB properties | No direct equivalent; storage mode and query folding settings | SQL-generation tuning is replaced by modelling and refresh design |
| Platform usage statistics | Workspace usage metrics | Adoption data keeps informing which reports survive the next phase |
Three lines in that table carry most of the risk, and all three are modelling lines rather than reporting ones: attribute chains, facts mapped to several tables, and Level Metrics. They are why we design against Microsoft's star schema guidance (opens in new tab) rather than importing the logical layer as it stands — our own Power BI star schema guide walks the same shape with worked examples. The measure work that follows is the Power BI data modeling and DAX half of the job, and Microsoft's Power BI migration guidance (opens in new tab) follows the same sequence: assess and prioritise the estate before rebuilding any of it.
MicroStrategy rewards normalisation. An attribute chain stored across separate lookup tables is exactly what the engine expects, and it resolves the joins for you at query time, so a deep snowflake costs the report author nothing. Power BI evaluates relationships inside the model, and long chains cost you twice: the engine traverses more relationships per query, and every measure that needs to reach across the chain gets harder to write and easier to get wrong.
Flattening is therefore not cosmetic tidying, it is the step that makes the DAX simple. One dimension table per business entity, with the whole attribute chain as columns and a hierarchy declared over them, is what the rest of the model is designed against.
| Consideration | MicroStrategy lookup-table schema | Power BI star schema |
|---|---|---|
| Where the chain lives | A lookup table per attribute level, joined by the engine | One dimension table holding every level as a column |
| Who resolves the joins | The SQL Engine, at query time, from attribute relationships | The model, once, through declared relationships |
| Cost of an extra level | Low: another lookup table and a relationship in the metadata | Paid at design time by widening the dimension, not per query |
| Effect on measure logic | Metric dimensionality settings handle the level | Filter context is explicit in DAX and reads the same everywhere |
| Effect on report authors | Attributes are picked from a browsable hierarchy | Columns and hierarchies sit in one table with display folders |
| Failure mode | A missing relationship produces a surprising join path | An ambiguous or inactive relationship produces a wrong or blank total |
| What we do about it | Collapse each chain into one conformed dimension, keep the surrogate keys, and reconcile row counts against the original lookup tables before any report is rebuilt | |
Level Metrics are the part of a MicroStrategy estate that most often surprises a migration team, because the behaviour is invisible on the report. A metric's dimensionality — its target, its grouping, and whether it filters standardly, absolutely, or ignores the filter altogether — changes what the number means without changing how it looks in a grid.
In Power BI that behaviour has to be written down. A metric fixed at the year level becomes a measure that removes the lower date filters; a percent-of-parent becomes a division by the same measure evaluated with the child attribute removed from context; a metric that ignored the report filter becomes one that removes that filter explicitly. The building block is the CALCULATE function (opens in new tab), and the discipline is naming: one measure per intent, documented, reconciled against its MicroStrategy original on the same filters and period before anyone signs it off.
Transformations get the same treatment against a marked date table, using standard DAX time-intelligence functions (opens in new tab). If your fiscal calendar is not a calendar year, or you run 4-4-5 periods, that surfaces here as a design decision instead of an assumption buried in the metadata.
Start by classifying, not rebuilding. A MicroStrategy project accumulates: the same grid report saved by four people, a dossier nobody has opened in a year, and a handful of documents that month-end genuinely depends on. Usage statistics and the metadata itself make that call evidence-based rather than political, and it routinely removes more work than the rebuild adds.
Surviving content splits cleanly. Anything a person explores becomes an interactive report on the shared model, with prompts rebuilt as slicers and field parameters so the filtering habits survive. Anything a person prints, files, or sends to a customer — the Report Services Documents side of the estate — becomes a paginated report (opens in new tab) in Power BI Report Builder, which gives exact page-layout control and prints every row across as many pages as it takes. Paginated reports depend on the capacity your workspace runs on, so confirm the licensing against Microsoft's current documentation before committing to a design.
Subscriptions and bursting need a decision rather than a translation. Per-recipient delivery maps onto Power BI subscriptions and a paginated-report delivery process, but not one for one, so we agree the delivery design with the recipients early instead of discovering it at cutover.
MicroStrategy usually enforces two different things that get discussed as one. Security filters, sometimes reinforced by connection mapping at the database, restrict which rows a user sees; object and folder ACLs restrict which content they can open at all. Those separate cleanly in Power BI, and keeping them separate is what makes the rebuild testable.
Row rules become row-level security (opens in new tab) roles on the semantic model. In most estates the security filter's attribute qualification becomes a security table — user, then the cost centres, regions or entities they may see — and the DAX filter matches the signed-in user against it, which keeps the rule in data rather than in code. Object visibility becomes workspace roles and app audiences. We document the mapping from your existing user groups so the security review at cutover is a comparison, not an investigation.
We scope the first phase as a departmental slice: one project schema area and the 20 to 50 reports and dossiers that depend on it. That is small enough to quote as a fixed scope at the Growth ($4,600) or Power ($8,000) block price point depending on how much modelling the area needs, and large enough to prove the model, the metrics and the security rules on real month-end data. Work after the first phase runs on prepaid Flex hours that never expire — Starter ($2,500), Growth ($4,600) or Power ($8,000), with hourly work from $100/hour — so the next project area is a scoped task, not a new negotiation.
Cost tracks the shape of the schema far more than the number of reports. A single-fact area feeding thirty grid reports is a much smaller job than three facts, a set of Level Metrics, deep attribute chains, and a security filter per business unit. You get an estimate in hours per deliverable, approve only what you want built, and unused hours stay banked. If you are also building the licensing case, our Power BI cost and pricing guide covers Microsoft's published licence tiers so the comparison uses their numbers rather than ours. See Flex pricing.
Individual reports typically ship within 3–5 business days of approval once the model is standing, and a phased migration is a sequence of those tasks rather than one project ending in a big-bang cutover. The model is the front-loaded piece: it is worth building and reconciling before the report queue starts, because every report after it gets cheaper.
Running MicroStrategy alongside Power BI for one full reporting cycle is worth the overlap. Users compare both outputs on live data, differences get explained rather than argued about, and the project area is switched off only once its replacement has been through a real month-end.
Finance, operations and IT teams carrying a MicroStrategy project they can no longer maintain comfortably: a schema only one person understands, a renewal that has stopped looking like value, prompt-driven reports nobody can self-serve, or a knowledge gap left by whoever built the metrics. It is a poor fit for anyone wanting a like-for-like screen copy with no modelling decisions made — that buys a more expensive version of the problem you already have.
project area per phase
reports in the first phase
own everything
Start with one department, not the whole project. Comparing routes off different platforms? The migration to Power BI hub covers them side by side, and the OBIEE to Power BI migration page covers the closest equivalent estate.
How it works
We document the project area you nominate — attributes and forms, relationships and lookup tables, facts and their grain, hierarchies, transformations, Level Metrics and security filters — and inventory the reports, documents and dossiers that use it, with owners and run frequency. You approve the list and the fixed scope behind it before work starts.
The schema becomes a star with flattened, conformed dimensions, explicit hierarchies and named DAX measures. Surviving reports are rebuilt on top of it highest-value first, prompts become slicers and field parameters, and anything that has to print becomes a paginated report.
Each rebuilt report runs beside its original on the same prompts and period, differences are explained, then we publish, set refresh, row-level security and permissions, walk your users through it, and stay available on the hours you have left for the next project area.
Representative perspective
The metrics were the surprise. Once someone wrote down what each level setting actually did, half the arguments about which number was right answered themselves.Finance systems manager, mid-market retailer
Representative perspective
Doing one project area first was the part that made it fundable. We proved the security rules on a department before anyone had to defend a whole-estate budget.IT director, multi-entity services group
Tell us which project area matters most and roughly how many reports hang off it. We'll scope the schema read and the rebuild as a fixed price, so you can see the real project before committing to it.
FAQ
No. Attributes, facts, hierarchies and transformations describe how the SQL Engine should assemble a query at run time, and there is no import path into a tabular model. What is systematic is reading the project metadata object by object and rebuilding it as a documented star schema with named DAX measures, so every definition has an owner who agreed to it.
A metric's level settings, its target, grouping and filtering, become explicit filter context in DAX. Percent-of-parent and share-of-total metrics turn into CALCULATE with REMOVEFILTERS or ALLEXCEPT; a metric that ignores the report filter becomes one that removes that filter by name. Each rewritten measure is reconciled against its MicroStrategy original before it is signed off.
In almost every case, yes. MicroStrategy resolves a chain of normalised lookup tables at query time, so a deep snowflake costs you little there. Power BI evaluates relationships in the model, and long chains cost performance and make measures harder to write. We collapse each attribute chain into one conformed dimension table per business entity.
A MicroStrategy security filter restricts rows for a user or group using an attribute qualification. In Power BI that becomes a security table mapping each user to the values they may see, plus a DAX role filter keyed on USERPRINCIPALNAME. We test the rebuilt roles user by user so the same people see the same rows after cutover.
One project schema area and the 20 to 50 reports and dossiers that depend on it, a departmental slice rather than the whole project. That is small enough to quote as a fixed scope, big enough to prove the model, the metrics and the security rules, and it leaves the rest of the estate in place until the department has closed a real month-end on Power BI.
This page covers the MicroStrategy path specifically, because the schema objects, Level Metrics and security filters set the scope here. If the reporting you are replacing started life in spreadsheets, the broader migration to Power BI service covers the Excel and SSRS routes on the same prepaid model. The closest neighbouring rebuilds are the other semantic-layer estates: OBIEE to Power BI migration, where the RPD plays the part the project metadata plays here, Cognos to Power BI migration, where a Framework Manager package does the same job, and Qlik to Power BI migration, where the logic lives in a load script and set analysis instead. The rebuild itself is Power BI data modeling and DAX work, and the shape we build towards is set out in our guide to star schema design in Power BI. Every task is scoped before work begins from your prepaid block of senior-led hours, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.