/ Insights / Choosing a Data and Analytics Modernization Partner on Azure Insights Choosing a Data and Analytics Modernization Partner on Azure November 12, 2026 Team Concurrency The most expensive data platform is the one that works and nobody uses. The pipelines run, the lakehouse is technically sound, the architecture diagram is clean, and six months later finance is still reconciling numbers in spreadsheets because nobody trusts the dashboards. The platform did not fail. The partner built the wrong things first, or left before the business rules, definitions, and ownership were settled. This guide is for data leaders and CIOs who have decided to modernize and are choosing who should do the work. Whoever you hire, it covers how to settle the destination first, five criteria that predict a trusted platform, a scorecard for your shortlist, and the questions to ask before you sign. Decide the destination before you choose the partner Evaluations go wrong when the buyer asks partners to pick the platform and hires the most confident answer. Settle the direction first, at least provisionally. On Azure, most organizations land on one of three paths. MICROSOFT FABRIC AZURE DATABRICKS MODERNIZE THE WAREHOUSE IN PLACE Existing skills SQL and Power BI teams, with Spark available when needed Strong Python, Spark, and data engineering teams Mature SQL and warehouse team that knows the current model well Workload mix BI-heavy, with growing data engineering and AI use Heavy data engineering, machine learning, and code-first work Stable, mostly structured reporting with predictable demand Governance posture OneLake catalog and Microsoft Purview across Fabric and Microsoft 365 Unity Catalog inside Databricks, with Purview integration for the wider estate Existing security model; governance gaps carry forward unless addressed Licensing and cost model Shared Fabric capacity used by every workload Consumption-based compute plus the underlying Azure resources Existing licenses and infrastructure; lowest change cost in the short term Strongest fit Organizations standardizing on Microsoft for data, BI, and AI Engineering-led teams or an existing Databricks estate Reporting that already works and needs better performance, not a new design Main risk Treating it as a Power BI upgrade and skipping platform design Business users left behind the engineering layer Deferring a migration that the AI roadmap will force later None of these is wrong for every organization. Fabric is the simplest path for most Microsoft-centric organizations because one platform runs from ingestion to Power BI. Databricks is strong for engineering-heavy teams, and many organizations run it alongside Fabric. If your warehouse performs and your team knows it well, modernizing in place can be the right call, as long as you are honest about what it must support in two years. For the architecture trade-offs in depth, see our comparison of data lakehouse vs. data warehouse and our guide to turning raw data into trusted insights with Microsoft Fabric. Ask every shortlisted partner which of these three they would advise you against, and why. A partner that recommends the same platform to every client is selling that platform. Five evaluation criteria that predict a trusted platform Credentials, team, and references are a first screen. Expect a current Microsoft Solutions Partner designation in Data & AI and named Fabric work, and be wary of a SQL Server practice relabeled for Fabric. For an organization of 500 to 25,000 employees, ask who will be on the project and whether senior architects stay past kickoff. Ask for references with your industry, similar source systems (multiple ERPs is common), and similar scale. If in-person workshops matter, a regional partner can be in the room. Most serious shortlists pass that screen, and these five criteria separate them. Governance designed in, not retrofitted Security, row-level access, sensitivity labels, catalog, lineage, and classification belong in the first design. Retrofitting governance is the most common and most expensive rework in data modernization: by the time someone asks who can see the margin data, hundreds of reports and copies exist. A strong partner will show you the access model and Microsoft Purview setup in the same design document as the pipelines. A partner that also delivers data governance and protection will treat this as part of the build. In one Fabric build for a leading industrial manufacturer, security, privacy, and access controls were built in from the start, and a medallion architecture (bronze, silver, gold layers) was chosen in part for data quality, lineage, and governance. For the practices themselves, see our guide to data governance best practices for analytics at scale. Migration method, not migration promise Every partner promises a smooth migration, so ask for the method. You want wave planning by business domain, a parallel run where old and new reports operate side by side, reconciliation rules that decide when the numbers tie, written cutover criteria, and a rollback plan. Then ask what they do when the numbers do not tie. The honest answer is that the problem is usually the business rules, not the pipeline. In a data platform assessment for a manufacturing organization, our review found the same data preparation and transformation logic duplicated across Power BI reports, with heavy transformations in overlapping semantic models causing refresh contention. No platform fixes that until the logic lives in one governed place. The assessment ended with a Fabric architecture recommendation and a sales-first roadmap, so the first implementation had a defined scope. Look for a partner that turns rules into code. The delivery plan for a trusted sales data foundation with Microsoft Fabric turns cross-ERP source-precedence and deduplication rules into documented, versioned, testable code, runs validation cycles with business stewards, and puts a written approval gate after the foundation milestone. Also ask which parts of your project use proven ingestion and validation patterns and which are custom, so you know what you are paying to build. Semantic layer and consumption design Business users decide here whether to trust the numbers, and this is where report builders and platform engineers part ways. Ask how the partner designs workspaces, medallion layers, and Power BI semantic models, including when they use Direct Lake, and whether reporting is designed with the business or handed over as tables for someone else to model. A good sign is a partner that defines the metrics before it builds anything. Consumption design also means planning for what comes after dashboards. Beyond this quarter’s reports, the gold layer should be ready to feed machine learning, AI agents, and live Power BI dashboards where the business needs them. Master data and quality ownership Ask who owns the definitions after the partner leaves. If “customer” and “active order” mean different things in each source system, a new platform will publish the disagreement faster. The answer you want names a mechanism and an owner: master or reference data that keeps entities consistent, scheduled quality rules, and data stewards with authority to settle disputes. In the industrial manufacturer’s Fabric build, master data management was deployed for consistency across systems, and the work ran in three phases (sales and margin, then purchasing, then inventory with days-on-hand tracking). Training and documentation meant business teams could maintain and extend the solution, and the client continues to add new data domains on its own. Ask to see handoff documentation from a past project. Cost and capacity management Modern platforms move cost from fixed infrastructure to consumption, and consumption needs watching. On Fabric, every workload draws from a shared capacity, so an unplanned Spark job or a heavy refresh can slow everyone else’s reports. On Databricks, cost follows cluster usage and the discipline of whoever configures it. Ask how the partner sizes capacity, separates development from production, and monitors usage afterward. On Fabric, a credible answer includes the Fabric Capacity Metrics app, a plan for scaling or pausing capacity, workspace-level visibility into who is consuming what, and the throttling and surge controls Microsoft provides. Then ask for an example of runaway cost they caught and how they caught it. A partner with FinOps discipline will have one ready. Evaluation scorecard Score each partner on evidence they can show you. CRITERION STRONG ADEQUATE WEAK Destination advice Recommends against an option for clear reasons tied to your skills and workloads Explains trade-offs but leans toward one platform Same platform recommendation for every client Governance designed in Purview, catalog, lineage, labels, and access model in the first design document Governance planned as a later phase with named scope “We can add governance later” Migration method Wave plan, parallel run, written cutover criteria, rollback; business rules in versioned, tested code Phased plan without written cutover or reconciliation criteria Big-bang cutover, or no answer for numbers that do not tie Semantic layer Metrics defined with the business before engineering; governed semantic models Semantic models built after data lands, reviewed with users Tables handed over for someone else to model Master data and quality Named owners, MDM or reference-data approach, scheduled quality rules Quality checks during the project only No position on who owns definitions Cost and capacity Sizing method, monitoring in place, a real example of runaway cost caught Sizing estimate without ongoing monitoring Cost discussed only as license price Handoff Training, documentation, hypercare, and a team that can extend the platform Documentation without structured knowledge transfer Ongoing dependency on the partner to change a report Team and references Named senior architects; references with similar sources and scale Credible references, team named after signing Team unnamed; references from unrelated work Questions to ask in a partner shortlist call Take these into the call as written. Each one has an answer you can check. Which of Fabric, Databricks, or modernizing our current warehouse would you advise us against, and why? Where will our business rules live when you are done: in reports, in people’s heads, or in versioned, testable code? What do you do when the numbers in the new platform do not tie to the old reports? What are your cutover criteria, and what is the rollback plan if a wave fails? Show us the access model and Purview design from a past project at the same stage as ours. Who defines the metrics, and when: before engineering starts or after the data lands? Who will own master data and data quality after you leave, and what mechanism supports them? What does your first phase deliver to a business user, and how will we know it worked? Who signs off between milestones, and what happens if the foundation is not right? How do you size capacity, and tell us about a time you caught runaway cost? Which named people will work on our project, and how much of their time is committed? What will our team be able to run and change on its own after you leave? If you only have time for one, ask the second. A precise answer usually means the rest has been thought through. Frequently asked questions What should I look for in a partner to build a scalable data lakehouse on Azure? Look for platform design depth beyond Power BI, governance in the first design, a written migration method, and a plan for who owns definitions afterward. Ask for references with similar source systems and scale, and who will be on the project. How do I evaluate a data migration partner for a move to a modern analytics platform? Ask for the method: wave planning, parallel runs, reconciliation rules, cutover criteria, and rollback. The most revealing question is what they do when numbers do not tie between old and new reports, because the answer shows whether they treat business rules as code or as an afterthought. Should our data platform partner also implement the data catalog and lineage? Usually, yes. Catalog, lineage, and classification are easiest to build alongside the platform and expensive to retrofit. On Microsoft, that means Microsoft Purview and the OneLake catalog designed with the pipelines, with sensitivity labels and access rules in place before reports are published broadly. Do we need a data and analytics roadmap before we choose a platform? A short assessment is worth doing first. It should inventory sources, reports, and business rules, recommend a direction, and define the first domain to build, which also lets you compare partner proposals on equal terms. Does master data management need to be part of an analytics modernization? If the same customer, product, or order means different things across your systems, yes. Without an approach to master data and named owners for definitions, a new platform reproduces the old disagreements. The approach can be a dedicated MDM tool or governed reference-data structures, but it has to exist. Is Microsoft Fabric or Azure Databricks the better choice? It depends on your team and workloads. Fabric suits organizations standardizing on Microsoft for data, BI, and AI. Databricks suits engineering-led teams with heavy Spark and machine learning work. Many organizations run both, with Fabric and Power BI serving the business. Should we choose a large global consultancy or a regional Microsoft partner? Choose the partner whose senior people will do the work. Large global consultancies bring breadth; regional partners often bring senior architects who stay through the handoff. At 500 to 25,000 employees, team continuity usually matters more than headcount. Where Concurrency, Inc. fits Concurrency, Inc. is a Milwaukee-based Microsoft systems integrator serving organizations across the Midwest, and we have helped clients adopt new technology since 1989. Our data analytics consulting practice builds on Microsoft Fabric, OneLake, and Power BI, and our data governance team works in Microsoft Purview, so governance is designed alongside the platform. Governance-first is our stated position. We start with an assessment, put business rules into versioned and tested code, define metrics with your business before engineering begins, and put written approval gates between phases. We work as an extension of your team, the people who design the platform stay through the handoff, and we use AI in our own delivery so senior time goes to the decisions that need it. If your current warehouse should stay, we will say so. Weighing your options? Request a data platform assessment and we will map your sources, reports, and business rules to a recommended direction and a phased plan, whoever you choose to build it.
