Frequently asked questions

Yes, we welcome visitors to our Leeds base for in-person workshops, discovery sessions, and project reviews. The London presence is more flexible and we typically meet London clients at their offices or at central London locations rather than at a fixed Hopton London office. Email hello@hoptonanalytics.com to arrange a visit.

Hopton publishes case studies selectively. We publish anonymised composites in our whitepapers and FAQs based on real engagements, with details obscured to protect client confidentiality. Named case studies are available where clients have explicitly agreed to public reference. Most of our client work is not published because the analytical advantage being created is the kind of thing clients prefer not to advertise.

Yes — Hopton publishes its frameworks publicly, and deliberately. Our governance framework, our trust framework for AI outputs (the Model Trust One-Pager and the Trust Storytelling Delivery Checklist), the Business Value Question, the Project Gate, the Analytics Maturity Model, and the FP&A Power BI playbook are all published in our whitepapers and FAQs. We share working templates with clients on request. Publishing the frameworks costs us nothing and helps the broader Microsoft data community.

Yes — Hopton serves clients outside the UK, but selectively. Our primary market is UK and Ireland mid-market businesses. We have worked with clients with international operations - multi-currency consolidation, cross-border data, international subsidiaries reporting up to a UK head office - and we have done specific projects for clients headquartered outside the UK. We are not a global consultancy and we are honest about that.

Hopton holds Microsoft Partner accreditation, with active work towards the Solutions Partner for Data and AI designation. Level 3 Pyramid Analytics accreditation. The team holds individual Microsoft certifications across the data and analytics stack. Accreditations are useful as one signal of capability but the work delivered for clients is the more important reference.

Hopton Analytics is a Microsoft data and analytics consultancy. We deliver Power BI, Microsoft Fabric, Azure Data Factory, and Microsoft Dynamics 365 Business Central reporting and analytics work for mid-market businesses across the UK and Ireland. Our work covers the full data and analytics stack, from extracting data out of operational systems through to executive dashboards, machine learning, and AI-augmented analytics. We are a delivery firm: we build the analytics estates we recommend rather than producing strategy documents and walking away.

Hopton Lens is our internal product offering: a multi-tenant, white-labelled AI Q&A tool built on top of Power BI semantic models using the Anthropic API. It allows business users to ask natural language questions of their certified semantic models and receive narrative answers with supporting data and sources. Lens is in active development and is offered to clients alongside Power BI and Fabric implementations. It is not a public product available for self-service; it is part of our consulting offer.

The Hopton Insight Series is our published library of whitepapers covering the topics mid-market data and analytics leaders care most about. Topics include Power BI at scale, the true cost of Power BI and Fabric, data governance, self-service BI, AI and Copilot, the analytics maturity model, and modernising analytics on legacy ERP systems. Each whitepaper includes the frameworks we use in client engagements. The series is available on our website. The frameworks are deliberately published rather than kept proprietary because most of the value is in the work of applying them, not the documents themselves.

We do not implement ERP systems (we work with the BC partner, not as the BC partner). We do not deliver Salesforce-specific work as a primary engagement. We do not work on non-Microsoft analytics stacks (Tableau, Qlik, Looker, Sisense) other than to migrate clients off them onto Power BI. We do not do generic IT consulting, software development, or cybersecurity work. Our scope is the Microsoft data and analytics stack, end to end.

Across 62 client organisations, Hopton has cut reporting time by an average of 70%, recovered an average of £127,000 in cost per engagement, and the governed reporting environments we build run at an average 94% data accuracy rate. These are averages across Analytics Acceleration Programme engagements, not projections for a single project, and the figures vary by starting point and scope. We can share anonymised reference architectures and outcome data relevant to your sector on request.

Hopton serves mid-market businesses across retail, wholesale and distribution, consumer goods (FMCG), construction, recruitment, professional services (law, accountancy, consultancy), commercial healthcare, and manufacturing. The Microsoft data and analytics architectural patterns transfer across these sectors; the dashboard libraries and the data sources differ. The pattern is sector knowledge built from real delivery rather than generic capability claimed without it.

Mid-market is our primary focus: typically £10 million to £500 million turnover, between 50 and 2,000 staff. Smaller businesses occasionally engage us for specific projects, and we have worked with larger businesses for specific data and analytics workstreams. The mid-market focus reflects where the Analytics Acceleration Programme works best and where our team's experience is concentrated.

Hopton specialises in the Microsoft data and analytics stack. Power BI for visualisation, semantic modelling, and self-service. Microsoft Fabric for the unified data platform (lakehouse, warehouse, data engineering, real-time intelligence, data science). Azure Data Factory and the broader Azure data services. Microsoft Dynamics 365 Business Central for the ERP integration work that often sits underneath analytics engagements. Microsoft 365 Copilot and Power BI Copilot for AI-augmented analytics. We do not work outside the Microsoft stack as a primary technology choice.

Leeds is our home and where the team is concentrated. We have a presence in London for client work and in-person engagements. Most of our work is delivered remotely with periodic in-person time on site, which suits the mid-market client base across the UK and Ireland. Geographic location of the client is rarely a constraint; we work with clients from Edinburgh to Cornwall and across Ireland.

The leadership team includes Simon Devine (Managing Director), Shauna Duffy (Director of Delivery and People, responsible for client delivery and team), Claire Harper (Head of Projects), Bryn Jones (commercial lead), and senior practice leads across data architecture, project management, and reporting. The structure is deliberately flat for a firm of our size. Clients work directly with the people who do the work; we do not run a model where a senior consultant pitches and a junior team delivers.

Leeds has a strong technology and financial services community, a mature Microsoft partner ecosystem, and excellent transport links to London, Manchester, and the rest of the UK. The team is largely Leeds-based and we have built our internal culture and operating rhythm around the city. The cost base is materially lower than London, which we pass through to clients as more competitive day rates without compromising on the calibre of the team.

We built our practice on Microsoft technologies because for most UK organisations, Microsoft is the right foundation - governed, scalable, and deeply integrated with the tools your teams already use. That focus has not changed. What has changed is that we have added Pyramid Analytics to our practice, because the best answer for AI-powered decision intelligence is not always a single-vendor stack. We are now Pyramid Analytics Partner of the Year alongside our Microsoft practice - which means we can recommend the right platform for your specific situation, rather than the one that fits our preferred toolset.

The Model Trust One-Pager and Trust Storytelling Checklist are available publicly, in line with our approach of publishing our frameworks rather than keeping them proprietary. They are referenced in our Hopton Insight Series and we are happy to walk through them directly with clients evaluating an AI-augmented analytics rollout.

These frameworks apply across Power BI, Fabric, and Pyramid, not just one platform. The underlying principle - grounding AI outputs in a trustworthy, documented semantic layer and communicating that trust clearly to users - holds regardless of whether the AI feature in question is Power BI Copilot, Pyramid's GenBI, or our own Hopton Lens tool.

You are probably not yet ready to invest in AI if your maturity score is below ten or your governance dimension is at Level 1. AI on bad data produces confident-sounding rubbish. The foundations matter. Most mid-market organisations need Building-stage maturity before AI investment pays back. Profile D and E organisations are usually ready; the others have foundation work to do first. The AI guide goes deeper on this.

Customer lifetime value (CLV) can inform M&A or fundraising where the customer base is a material asset. For consumer brands, subscription businesses, and ecommerce companies being acquired or seeking investment, the CLV of the customer base is a key valuation input. Buyers want to understand not just current revenue but the predicted forward revenue from the existing customers. A defensible CLV model with validated accuracy strengthens the valuation case. Several of our clients have used CLV outputs in funding rounds and acquisition processes.

Copilot in Power BI can attempt to, and this is exactly where governance work matters: a poorly modelled semantic layer with ambiguous relationships or missing measures can lead Copilot to generate a plausible-sounding but ungrounded answer. Rigorous semantic model design - the same discipline that makes any Power BI report trustworthy - is the primary defence here, not a separate AI-specific control.

GenAI can summarise your internal documents, and this is one of the most reliable applications. The pattern: a RAG system grounded on the document set, with prompts designed to produce specific structured summaries (key facts, decisions, action items, risks). The output is consistent enough to use in workflow automation. Common applications include meeting summaries, contract reviews, RFP analysis, compliance review, and competitive intelligence. The foundation model handles the summarisation; RAG ensures it is grounded on the right documents; prompt engineering controls the output structure.

Yes — Hopton can build custom Copilots for you, where the use case definition is solid. We do not generally take on Copilot Studio engagements where the use case is loosely defined; experience shows these become research projects that disappoint. We do take on Copilot Studio engagements where the use case has a defined audience, a defined task, and a defined success measure. The early discovery work to define the use case is part of every Copilot engagement. Sometimes the discovery output is a recommendation against Copilot Studio in favour of a different solution.

Yes — Hopton can help us decide which Copilot to invest in first. The AI Readiness Assessment (a four-week fixed-price engagement) covers the Copilot prioritisation explicitly: which Copilot products fit which use cases in your business, what the foundations need to be, and what the sequencing should look like. Output is a written assessment with a clear recommendation. The assessment is independent of any subsequent build engagement.

Yes — Hopton can run a quick ML proof of concept for our business. The AI Readiness Assessment (a four-week fixed-price engagement) covers an ML proof of concept on top of the broader readiness work. Output includes a working model on a real use case, the Model Trust One-Pager applied to the output, and a written recommendation on whether to take the model into production. The assessment is independent of any subsequent build engagement. We have written assessments recommending against ML deployment where the foundations were not ready.

Yes — machine learning can predict sales pipeline conversion, with enough historical data. Models trained on past won and lost opportunities can predict win probability based on deal characteristics: account size, deal value, stage progression speed, activity volume, the rep working the deal. The output is a per-opportunity score that supplements the human judgement of the sales rep. The score is a flag for review, not a decision; sales is too relationship-dependent for the model to act autonomously. We typically deploy these as monitoring agents on top of certified pipeline models.

Whether ML can run autonomously or needs human review depends on the cost of being wrong. Low-stakes, high-volume decisions (which marketing email variant to send) can run autonomously. High-stakes decisions (which customers to call about retention, what to forecast for the board, what credit limit to set) need human review of model outputs. The pattern we use is monitoring agents that flag and route to humans, retrieval agents that surface information without acting, and only narrow action agents in tightly-scoped reversible scenarios. The trust framework matters more for ML than for static reporting because the model can be confidently wrong.

No — Power BI Copilot cannot yet replace traditional report authoring, and probably not, and probably not for some time. Copilot accelerates authoring but does not replace it. The judgement calls about visual hierarchy, dashboard layout, semantic model design, and DAX optimisation still require human authorship. The pattern that works is Copilot as a productivity tool for capable authors, not Copilot as a replacement for the authoring discipline. Authors who use Copilot well produce better work faster. Users who try to use Copilot without authoring skills produce reports that should not have been published.

Yes — RFM can be built entirely in Power BI without Fabric or Python, for moderate customer volumes. The technique is achievable in DAX with the right semantic model design. The pattern: a Sales fact tagged with customer and date, a Customer dimension, and DAX measures for Recency, Frequency, and Monetary calculations. Quintile or quartile scoring is implemented through PERCENTILE.INC or similar DAX functions. The segment assignment is implemented through SWITCH logic on the three scores. For up to a few hundred thousand customers this works well in Power BI alone.

Yes — RFM segments can inform clienteling and account management, particularly in B2B and high-value retail. The customer-level segment assignment, surfaced in the CRM, lets account managers see which customers need attention, which are at risk, and which are growing. For B2B sellers and luxury retail clienteling teams, the segment alongside the transaction history becomes the standard view in the CRM. The integration with the CRM (Dynamics, Salesforce, HubSpot) is part of the activation work.

Smaller mid-market organisations can realistically do proper AI governance, and it does not need enterprise-scale process to do well. A properly documented Model Trust One-Pager and a clear internal owner for semantic model quality covers most of what a mid-market organisation genuinely needs, without requiring a dedicated AI governance function.

The forecasting and optimisation modelling itself is typically built using Fabric's data science workload (Python or R-based modelling against your data), with Power BI used to present the resulting recommendations and scenarios to business users. Power BI alone does not include the modelling capability needed; Fabric (or an external data science environment feeding back into Power BI) is required for the modelling step.

AI chatbots for customers or employees are useful when the use case is well-defined. The pattern that works: a defined audience (customers asking specific kinds of questions, employees querying specific knowledge), a defined task (look up information, answer specific question types), and a clear success measure (resolution rate, satisfaction, escalation rate). The pattern that fails: a vague aspiration to have a chatbot that handles everything, deployed to a broad audience without clear use case definition. The vague chatbots produce frustrated users; the focused chatbots produce real value.

Yes — you can run a CLV proof of concept. We extract a sample of historical customer transaction data, fit a probabilistic CLV model, validate it against held-out data, and walk you through the results. The proof of concept produces real CLV estimates for your real customers, with the validation evidence to defend the numbers. Three to four weeks is the typical duration. The output is usable directly for strategic conversations even before the full implementation.

Yes — you can run a custom GenAI proof of concept. A four to six week proof of concept produces a working RAG application on a defined use case with your real data. The proof of concept output is functional enough to validate the approach and demonstrate the achievable quality. Several of our custom GenAI engagements started as proofs of concept and grew into production applications. The proof of concept is the right way to de-risk the broader investment.

Yes — you can run a quick RFM proof of concept, in two to three weeks. We extract a sample of historical transaction data, build a working RFM segmentation, produce the segment summary and a customer-level export, and walk you through the results. The proof of concept produces real segments on your real data, not a hypothetical demonstration. The output is usable directly if the proof of concept lands well. The cost is a small fraction of a full implementation and the value is high.

You can use Microsoft Fabric for RAG partially, with some limitations. Fabric's Lakehouse and OneLake can store the raw documents and the generated embeddings. Fabric Data Engineering pipelines can handle the indexing workflow. The retrieval and generation typically happen outside Fabric, through Azure AI Search and Azure OpenAI Service. The Fabric layer provides the data foundation; the AI services provide the reasoning. The integration is straightforward through standard APIs.

Yes — you can use Python and standard data science tools throughout. Fabric Data Science notebooks support Python and R natively, with the standard libraries (pandas, scikit-learn, TensorFlow, PyTorch, statsmodels, Prophet) available. The development experience is familiar to data science teams who have worked in Jupyter or Databricks. The integration advantage is that the notebooks have direct access to OneLake data without separate connectors, and trained models deploy into the same Fabric environment without separate infrastructure.

Yes — you can use models other than OpenAI on Azure. Azure AI Foundry provides access to a model catalogue including Microsoft's own Phi models, Meta's Llama models, Mistral's open-source models, and others. The choice of model has implications for cost, capability, and licensing. For most mid-market applications, the OpenAI models offer the best capability-to-cost balance, but specific use cases (high-volume on-premises deployment, specific compliance requirements) may favour alternatives. The architecture supports multiple models within a single application where appropriate.

No — AI did not create the trust problem in analytics. AI made the trust problem visible. Human-produced analysis came with slow trust signals: the analyst standing in front of the chart, answering questions, with their reputation on the line. AI strips those signals away. Outputs land on a desk with confidence and no provenance. The trust problem was always there. Statistical work used to surround itself with conventions (citing sources, showing your working, admitting where a model is weak). AI removed the conventions. The fix is to put them back.

You effectively do need a data lake before doing ML. ML training and inference need access to historical data in a form that is performant and queryable. A data lake (Microsoft Fabric Lakehouse, in our standard architecture) is the right foundation. Building ML directly on operational systems without a lakehouse is technically possible but produces fragile pipelines and poor performance. The Fabric implementation is usually the precondition for serious ML work, not a parallel investment.

Yes — we frequently recommend holding off on AI investment. If your data foundations are not ready, AI investment will produce confident-sounding rubbish at scale. We will tell you to defer AI work and do the foundation work first, even though we will not be doing the deferred AI work ourselves. The four-week assessment is fixed-scope and fixed-price; we have no incentive to push you into AI work that will fail.

AI governance does not necessarily mean restricting what AI features users can access for its own sake - it means being deliberate about what those features are grounded in and being transparent with users about what they can and cannot rely on. In practice, this looks more like proper semantic model design and clear communication than blanket feature-blocking.

Yes — Hopton does build custom generative AI. Custom GenAI is part of our delivery scope alongside the Microsoft Copilot work covered in the Copilot for Mid-Market FAQ. Engagements typically include the use case definition, the RAG architecture design, the implementation on Azure OpenAI and Azure AI Search, the prompt engineering and evaluation work, and the operational integration. The trust framework runs through every engagement; we do not deploy GenAI without it.

Hopton does not guarantee a specific margin or cost improvement from price or inventory optimisation work, and we would be sceptical of anyone who does. These models improve the information available for pricing and stocking decisions; the actual outcome still depends on how the business acts on that information, competitive dynamics, and factors outside any model's scope. We frame engagements around better-informed decisions, not guaranteed financial outcomes.

Yes, across M365 Copilot, Power BI Copilot, Fabric Copilot, and Copilot Studio. The work spans the technical implementation, the data foundations that determine whether Copilot output is trustworthy, and the adoption work that determines whether the investment pays back. Many of our Copilot engagements are extensions of existing Power BI or Fabric implementations where the foundations are already in place. Standalone Copilot engagements typically start with a foundation assessment to surface what needs to be ready before Copilot rollout.

Yes — Hopton includes AI governance in every Copilot, GenBI, or Hopton Lens engagement, as standard rather than an optional add-on. Given how directly trust in AI-generated outputs affects whether an analytics rollout actually gets adopted (or gets quietly distrusted and ignored), we treat this as core delivery work rather than a separate governance workstream.

Machine learning is one of the capabilities we deliver alongside Power BI, Microsoft Fabric, Azure Data Factory, and Business Central work. ML engagements span demand forecasting, customer segmentation, churn prediction, anomaly detection, and project margin forecasting (for construction clients particularly). The team includes data scientists and analytics engineers with practical experience deploying ML in mid-market production environments. ML is not the entirety of what we do, but it is a core capability and we deliver it regularly.

Yes, properly implemented RLS and other security controls apply to GenBI and Copilot answers exactly as they do to standard reports, provided the AI feature is correctly integrated with the semantic model's security layer rather than bypassing it. Confirming this is genuinely enforced, not just assumed, is a standard check in any AI-augmented analytics rollout.

No — the Model Trust One-Pager does not only apply to AI, and that is part of the point. The framework was built for AI but the discipline applies further. Every analytical output going into a decision benefits from the structure: forecasts, dashboards, ad-hoc analysis, executive summaries. All face the same trust problem AI made visible. Many clients have started applying the seven blocks to non-AI work for the same reason: it makes the work safer to act on.

Price and inventory optimisation does not replace the judgement of experienced buyers or pricing managers, and we would not recommend positioning it that way. The intent is to give experienced people better information to apply their judgement to, particularly for the volume of routine pricing and stocking decisions that are hard to give proper individual attention to manually, not to remove human judgement from decisions where it adds real value.

Using AI features can, depending on what data the AI feature has access to and how it is used, which is why grounding AI answers in an already-governed semantic model (rather than an open connection to raw data) matters as much for privacy as for accuracy. Standard data governance practices - row-level security, sensitivity labels, access control - apply to AI features exactly as they do to any other reporting surface.

CLV predictions are variable in accuracy, by individual customer. Probabilistic CLV models have substantial uncertainty for individual customers because future behaviour is genuinely uncertain. The aggregate-level predictions (total CLV across a segment or cohort) are usually more accurate than any individual prediction because the individual errors cancel out. The honest framing is: do not over-rely on the individual customer estimate, but the aggregate is reliable enough to inform strategy. The Trust Storytelling Delivery Checklist applies here particularly; the model output should travel with limits and confidence framing.

Email hello@hoptonanalytics.com with a brief description of your customer base, the length of relationships you typically have, and the commercial decisions you would inform with CLV. The first conversation is exploratory and free. If there is a fit, we propose either a focused CLV implementation or a broader customer analytics engagement that includes CLV alongside RFM and other techniques.

Email hello@hoptonanalytics.com with a brief description of your current Microsoft estate, your AI ambition, and any specific Copilot products you are considering. The first conversation is exploratory and free. If there is a fit, we propose an AI Readiness Assessment as the structured next step. Sometimes the conversation surfaces that Copilot is not the right next investment, in which case we say so.

Email hello@hoptonanalytics.com with a brief description of the decision you would like to inform with ML, your current data state, and any previous ML attempts. The first conversation is exploratory and free. If there is a fit, we propose either an AI Readiness Assessment (broader scope) or a focused four-week ML proof of concept (narrower scope) as the next step.

Email hello@hoptonanalytics.com with a brief description of your customer base, your transaction data shape, and what you would do with the segments once you have them. The first conversation is exploratory and free. If there is a fit, we propose either a focused RFM implementation or a broader customer analytics engagement that includes RFM as one component.

Email hello@hoptonanalytics.com with a brief description of the use case (the audience, the task, the data sources, the success measure) and any existing AI investments. The first conversation is exploratory and free. If there is a fit, we propose either a focused proof of concept or a broader AI Readiness Assessment that situates the GenAI work within your overall data and AI strategy.

We activate RFM segments in marketing automation through the marketing automation platform reading the segment assignments. The pattern: the lakehouse exports the segment assignments to the marketing platform (HubSpot, Marketo, Klaviyo, Dynamics Marketing, ActiveCampaign), which uses them to drive campaign targeting. Champions get loyalty rewards. At-risk get retention campaigns. Hibernating get reactivation campaigns. New customers get onboarding sequences. The activation is the point of the RFM work. Building segments without activation produces dashboards that nobody acts on.

We customise RFM segments for your business by starting with the standard segments and adjusting the boundary scores based on the specific business. A B2B business might want fewer segments because the customer base is smaller. A retailer with high purchase frequency might want finer granularity in the Frequency dimension. The customisation pattern is empirical: build the segments using standard rules, look at where customers actually fall, and adjust the boundaries to produce groups that are commercially meaningful. The starting point is generic; the final segment definition is business-specific.

Email hello@hoptonanalytics.com describing your current pricing or stock management process and where the biggest pain point sits - stockouts, excess stock, or pricing that has not kept pace with demand. We will give an honest view of whether your data and business size make this a good fit before scoping any work.

Email hello@hoptonanalytics.com describing your current or planned use of Copilot, GenBI, or AI-augmented analytics features. We can run a focused Model Trust review of your existing semantic models, independent of any wider engagement, as a starting point.

We handle a case where Copilot or GenBI gives a wrong answer by having a clear, known escalation path - who to tell, and how the underlying semantic model or documentation gets corrected - rather than treating an isolated wrong answer as an unfixable AI quirk. Every wrong answer is also useful signal about a gap in the semantic model's clarity that is worth closing.

There are two main patterns for handling seasonality in RFM customer segmentation. The simpler approach is to use a long enough lookback window that seasonal effects average out (typically two years or more). The more sophisticated approach is to calculate season-aware Recency: a customer who normally buys in November and has not bought yet in October is not at risk, while a customer who normally buys monthly and has not bought for two months is. Most mid-market RFM implementations use the simpler approach. The sophisticated version is worth the work for businesses with strong seasonality.

We know if a machine learning model is good enough to deploy through specific evaluation against the use case it serves. Generic accuracy metrics (precision, recall, AUC) are necessary but not sufficient. The deeper question is whether the model performs in the segments that matter most: the high-value customers, the new product lines, the regions with different patterns. A model that is 92 per cent accurate overall but wrong on the top ten customers is not a deployable model. The Trust Storytelling Delivery Checklist (covered in our Governance FAQ) is the operational standard we apply to every ML output going into a decision.

A semantic model's readiness for standard reports (correct relationships, tested measures, proper RLS) is necessary but not fully sufficient for Copilot or GenBI. Additional readiness checks include clear, unambiguous measure naming (since AI features often work directly from metadata labels), documented metric definitions, and testing how the AI feature behaves against edge cases and ambiguous questions before wider rollout.

We measure Copilot ROI through specific metrics tied to the use cases deployed. For M365 Copilot: time saved per user on routine tasks, validated through user surveys and observed usage patterns. For Power BI Copilot: speed of authoring, quality of generated content, adoption of self-service Q&A. For Copilot Studio: cost per resolved query versus the alternative channel. Decision Adoption Rate (the metric in our Self-Service BI FAQ) applies to Copilot outputs going into decisions. Measuring ROI is harder than measuring activity, but only the ROI measurement justifies the investment.

We model customer lifetime value for B2B with infrequent large purchases carefully. B2B with infrequent purchases violates the assumptions of probabilistic CLV models built for retail patterns. The right approach is usually a custom model tailored to the business: account-level analysis, opportunity-stage analysis, contract-renewal analysis. The output is still a forward-looking value estimate per customer, but the technique is bespoke rather than off-the-shelf. We have built B2B CLV for distribution and professional services businesses; the patterns are recognisable but the implementations are not standardised.

We validate a customer lifetime value (CLV) model through holdout testing on historical data. Take customers acquired more than two years ago, build the model using only their first 12 months of behaviour, and predict their next 12 months. Compare the predictions to the actual outturn. Metrics like mean absolute percentage error (MAPE) at the customer level, and aggregate accuracy at the segment level, give a defensible measure of model quality. Validation is essential before the CLV outputs are used for material decisions.

To visualise RFM in Power BI, three views work well together. A segment summary table showing customer count, revenue, and average value per segment. A segment migration sankey or matrix showing how customers moved between segments period-over-period. A drill-through to individual customers within a segment. The most useful view depends on the audience: marketing teams use the migration view, account managers use the customer drill-through, leadership uses the summary table. Build all three and surface the right one for each audience.

Copyright, IP, and ethical concerns with generative AI are real concerns that need real attention. The training data of foundation models is the subject of ongoing legal discussion; outputs may reproduce or paraphrase copyrighted material. The right discipline is to treat foundation model outputs as drafts that need human review rather than as final content. For internal applications grounded on your own data through RAG, the copyright concern is lower because the outputs are derived from your authorised content. For content generation applications, human review and editorial discipline before publication is the right pattern. The technology is moving fast; the legal and ethical frameworks are evolving alongside it.

We present optimisation recommendations to business users by presenting them alongside their rationale and confidence level, not as an unexplained "black box" number - showing the demand assumption behind a recommended price, or the service level trade-off behind a suggested reorder point, so a buyer or pricing manager can sanity-check and ultimately own the decision rather than blindly follow a model.

Preventing hallucination in a custom generative AI solution takes four disciplines. Strong RAG with quality retrieval that provides genuinely relevant context. Prompts that instruct the model to refuse to answer beyond the provided context. Citation requirements that link generated content to source documents. Evaluation that tests for hallucination on known cases. The combination produces systems where the model cites its sources and refuses to answer questions the source material does not support. Without these disciplines, the system produces confident-sounding inventions, which destroys trust faster than the application produces value.

We validate that a price or inventory model is actually working before relying on it by testing recommendations against a controlled subset of products or a defined time period, comparing actual outcomes to what the model predicted, before extending recommendations more broadly. We would not recommend applying model-driven pricing or stocking decisions across an entire range without this kind of validation step first.

AI work fits the Analytics Acceleration Programme naturally, because it is iterative. Build the first use case, get the trust framework working in practice, deploy it, learn what worked, expand into the next use case. Each cycle takes weeks, not months. The trust framework gets sharper with each one. The AAP gives you a dedicated allocation of consulting days each month over twelve or twenty-four months, which is the right shape for AI work that needs to evolve as the technology and your organisation evolve.

Azure AI Search provides a unified search experience combining vector search, keyword search, and semantic ranking. Documents are indexed with embeddings generated by Azure OpenAI; queries are converted to embeddings and matched to the most similar document chunks; the results are returned with citation metadata. The integrated approach (vector plus keyword plus ranking) usually produces better retrieval quality than vector search alone. For mid-market RAG implementations, Azure AI Search handles the retrieval layer with relatively low operational complexity.

CLV informs acquisition spend by providing a defensible ceiling on customer acquisition cost (CAC). The basic rule: CAC should be a fraction of CLV, with the fraction depending on the business. For most mid-market businesses, CAC up to 30 per cent of CLV is healthy; up to 50 per cent is acceptable for growth phases; above 50 per cent indicates over-paying for customers. The CLV figure makes the conversation specific. Marketing channels with high CAC relative to the CLV of customers they produce can be reduced; channels with low CAC relative to CLV can be expanded.

CLV informs retention spend by prioritising retention investment on customers worth keeping. The retention team has limited capacity (call hours, email touches, account management time). CLV tells them which customers deserve the investment. High-CLV customers showing churn signals get the retention treatment. Low-CLV customers showing churn signals are accepted as natural attrition. The retention spend per customer can be calibrated against the customer's CLV: the breakeven retention spend is the CLV times the probability the spend prevents churn.

CLV informs segmentation through a value-aware overlay on behavioural segmentation. RFM segments customers by behaviour. CLV adds the value dimension: a high-value Champion gets different treatment than a low-value Champion, even though both fall in the Champion segment. The combined view (RFM segment plus CLV) is one of the highest-resolution customer views available in mid-market analytics. The marketing automation can be calibrated to this combined view, treating high-value at-risk customers more carefully than low-value at-risk ones.

Hopton typically builds CLV as part of a broader customer analytics engagement following on from RFM, or as a focused six to eight week implementation when the foundations are in place. The implementation includes the data review, the model selection (probabilistic versus simpler approaches based on the business shape), the build in Fabric Data Science, the validation against historical data, the visualisation in Power BI, and the activation pattern with marketing or finance. Working CLV outputs are typically available within four to six weeks; full activation takes another two to four weeks.

Hopton typically builds RFM as part of a broader analytics engagement covering customer analytics, or as a focused four to six week implementation when the data foundations are already in place. The implementation includes the data review and cleansing, the segment definitions worked out with the marketing team, the technical build in Power BI or Fabric, the visualisation, and the activation pattern with the marketing or CRM systems. The first useful segments are typically live within four weeks; the full activation takes another two to four weeks of integration and refinement.

Hopton uses this maturity model as the first thing we work through with every new client. We score each dimension independently with the client's team, then compare. The gaps between what leadership thinks and what the data team knows are often the most valuable part of the conversation. The assessment then feeds directly into a roadmap: what to fix first, what to invest in, what to leave alone. That roadmap becomes the backlog for our Analytics Acceleration Programme.

ML model maintenance works by managing drift: models drift as the underlying data and business conditions change. The maintenance pattern includes regular performance monitoring against ground truth, scheduled retraining (typically monthly or quarterly depending on data volatility), and explicit version control so model changes are visible to stakeholders. Silent changes to models destroy trust faster than initial deployment failures. Every ML output going into a decision should travel with the Model Trust One-Pager (the seven-block framework in our AI/ML whitepaper) showing freshness, limits, and change history.

A custom GenAI engagement differs from a Copilot engagement in three ways. The use case definition matters more, because custom GenAI has higher build cost and tighter benefit window. The architectural design is more involved, with RAG components, vector store, model selection, and orchestration to specify. The evaluation discipline is more rigorous, because there is no Microsoft product team validating the application for you. The engagement timeline is typically 8 to 16 weeks for a focused custom GenAI build, longer than a comparable Copilot rollout.

A price or inventory optimisation engagement typically starts usually as an extension of an existing Power BI or Fabric engagement where demand forecasting or margin reporting is already in place, since that foundation significantly reduces the additional data work needed. Starting from scratch without existing forecasting or margin reporting is possible but takes longer, since the foundational data model needs to be built first.

A semantic layer reduces AI hallucination risk by giving the AI a single, well-defined, mathematically precise source of truth for what each metric means, rather than leaving it to infer meaning from ambiguous or inconsistent data. This is the same principle underlying why ServiceNow's acquisition of Pyramid Analytics was framed around grounding AI agents in a trusted semantic layer, and it applies equally to Power BI Copilot grounded in a well-built semantic model.

Customer churn prediction works through a classification model trained on historical customer data: who churned, who did not, and what was different about them. Common features include time since last purchase, change in purchase frequency, support ticket history, contract value, and engagement with marketing. The model produces a churn probability per customer, which feeds the retention team's prioritisation. The trust framework matters here particularly: false positives waste retention spend, false negatives lose revenue. The prediction is most useful as a flag for review, not an automated trigger.

Customer lifetime value modelling works on a different model for a subscription business. For contractual relationships (subscriptions, contracts with defined terms), the modelling shifts to churn-based: predict the probability of churn at each renewal point, compute expected lifetime under those probabilities, multiply by the contractual value. Probabilistic CLV models for non-contractual relationships do not apply directly. The data needed is the contract history and the churn history. The maths is different but the principle is the same: predict future value based on historical patterns.

Customer service AI works through a RAG architecture grounded on the company's product documentation, policies, and historical support cases. The user asks a question through chat or voice; the system retrieves relevant context; the model generates an answer with citations to the source material. Successful implementations include three discipline points: clear escalation paths to human agents, conservative answering on questions outside the knowledge base, and continuous improvement based on actual customer interactions. The technology is the easy part; the operational discipline is what determines whether the implementation succeeds.

Natural-language analytics translates a plain-English question into a query against your semantic model and returns a chart or answer. Because it depends entirely on that model, clean, well-named tables and agreed measures produce good answers, while a messy model produces confident nonsense. That is why the semantic model matters more in the AI era, not less — the preparation that makes conversational analytics reliable is the same modelling discipline good analytics always needed.

Natural-language querying works like this: in Power BI, a question typed into Copilot or a Q&A visual is matched against the certified semantic model, not the raw tables. The model's field names, synonyms, and relationships are what let "show me revenue by region last quarter" resolve into an actual query, because the model already defines what "revenue" and "region" mean and how they relate. The engine turns that into a query against the model, picks a suitable visual for the result, and can generate a short written summary alongside it. Two things determine whether this works well in practice rather than producing a confidently wrong answer. First, model quality: vague or duplicated field names produce vague or wrong matches, so the same certified-model discipline that makes ordinary reports trustworthy is what makes natural-language querying trustworthy. Second, governance carries through automatically, since the query still runs inside the semantic model's row-level security, so a user cannot ask their way into data they would not otherwise be able to see. We treat natural-language querying as a feature layered on top of a governed model, not a replacement for building one.

The Hopton trust framework applies strongly to GenAI. The Model Trust One-Pager from our AI/ML whitepaper applies to GenAI outputs as it does to ML predictions: every output going into a decision should travel with sources, freshness, limits, confidence framing, recommended action, and change history. For RAG-based applications, the citation discipline is the most important practical implementation: outputs cite their sources, users can verify the citations, and ungrounded answers are explicitly flagged. The trust framework is more important for GenAI than for traditional ML because the GenAI output sounds more authoritative regardless of whether it is right.

The assessment connects to the rest of the Hopton Insight Series by pointing to the relevant guides: each guide in the series is most relevant to specific maturity profiles. Profile A and B benefit most from the Governance and BC guides. Profile C and D need the Power BI at Scale and Self-Service guides. Profile D and E are ready for the AI and Fabric guides. The maturity assessment tells you which guides to read first, which is why we recommend starting here.

The data flow in a Fabric implementation starts at the Bronze layer, which captures raw transaction data from the source system. Silver cleans and deduplicates customers, standardises product codes, applies any business rules. Gold contains the customer-level Sales fact with all the dimensions joined. The RFM notebook reads Gold, calculates the scores and segments, and writes back to a dedicated RFM Delta table. Power BI semantic models read the RFM table alongside the customer and sales data. The architecture is the standard Bronze/Silver/Gold pattern with RFM as one of several Gold-layer assets.

This connects directly to Hopton's broader Data Governance framework — the Business Value Question, the four practices, and the Project Gate covered in our main Data Governance FAQ apply to AI-augmented analytics as much as to standard reporting. The Model Trust One-Pager and Trust Storytelling Checklist are the AI-specific extensions of that same underlying discipline, not a separate framework running in parallel.

This relates directly to the demand forecasting work Hopton already does in Microsoft Fabric — demand forecasting is the foundation both price and inventory optimisation build on. A reliable forecast of future demand is a prerequisite for sensible price elasticity modelling and for calculating appropriate stock and reorder levels; these are extensions of that existing capability rather than a separate discipline built from scratch.

CLV is built in Microsoft Fabric through a Fabric Data Science notebook reading transaction data from the lakehouse. For probabilistic CLV in non-contractual settings, the notebook uses the lifetimes Python library to fit BG/NBD and Gamma-Gamma models. The output is per-customer CLV estimates over a defined prediction horizon (typically 12 or 24 months). The notebook writes the estimates back to the lakehouse as a Delta table. Power BI semantic models read the CLV table for reporting, alongside customer and transaction data. The pipeline runs on schedule (typically monthly) so the estimates stay current.

ML differs from regular reporting in what it does: regular reporting describes what happened. ML predicts what will happen, classifies what something is, or finds patterns the human eye misses. A revenue dashboard reports last month's sales; an ML model predicts next month's sales by customer with a confidence interval. A customer list shows who you have; an ML segmentation groups them by behaviour into actionable cohorts. The two are complementary, not competing. ML works best on top of clean reporting foundations, which is why we treat it as a later-stage capability rather than a starting point.

RFM is built in Microsoft Fabric through a notebook in Fabric Data Science (Python or Spark) reading transaction data from the lakehouse. The notebook calculates Recency, Frequency, and Monetary per customer, applies the scoring rules, assigns segments, and writes the segment assignments back to the lakehouse as a Delta table. Power BI semantic models pick up the segment assignments through Direct Lake mode for reporting. The pipeline runs on schedule (typically nightly) so segments stay current. The pattern is well-established and we have reusable notebook templates.

Azure OpenAI Service operates within the Azure data boundary. Prompts and responses are not used to train the underlying foundation models. The same governance applies as for other Azure services: sensitivity labels, data classification, access controls, audit logging. For most mid-market businesses on Microsoft Azure, the data privacy framework around custom GenAI is the same as around any other Azure data service. The board is right to ask; the answer is solid for the standard Azure commercial agreement.

Machine learning is used in finance and FP&A in several specific patterns. Cash flow forecasting using historical patterns and pipeline data. Anomaly detection in expense and supplier data for finance integrity work. Driver-based forecast modelling for FP&A. Working capital optimisation. The use cases pay back through faster, better forecasts and through finding issues that manual review misses. ML in finance benefits from the FP&A foundations being clean first; ML on top of inconsistent finance data produces confident-sounding rubbish, which is worse than no ML at all.

A Copilot adoption takes six to twelve months for full adoption to bed in, with visible value in the first three months for well-targeted rollouts. Shorter than three months usually means the rollout is happening on weak foundations and the value will not stick. Longer than twelve months usually means the change management workstream is being neglected. The 6 to 12 month window is the right horizon for a serious Copilot adoption programme.

An initial price or inventory optimisation project takes eight to twelve weeks: building an initial working model and validating it against a representative product range or category typically takes eight to twelve weeks, depending on data quality and how much historical price or demand variation already exists to learn from. Full-scale rollout across a complete product range is usually phased after an initial category proves the approach works.

The Model Trust One-Pager adds roughly two minutes of extra work per output. It is the difference between work that gets ignored and work that gets acted on. The cost is small. The return is meaningful. Most of the underlying information already exists in the work; the framework is mainly about surfacing it consistently in the same place every time.

How much historical data you need depends on the use case. Customer segmentation works on as little as 18 months. Churn prediction needs at least two years to capture seasonal patterns. Demand forecasting wants three to five years for products with annual cycles. Customer lifetime value modelling wants 18 to 24 months minimum. Time-series and pattern-based models need enough history to see the variation they are trying to predict. New businesses with limited history are more constrained on what ML can deliver; established businesses with years of clean data have more options.

RFM and CLV modelling need eighteen months of history as a working minimum, two years as the recommended target, three to five years for the most stable segments. Eighteen months captures one annual cycle plus the recent recency window. Two years provides better seasonality handling. Beyond three years, additional history adds diminishing value because customer behaviour changes meaningfully over longer windows. For new businesses with less than 18 months of data, RFM still works but the segment definitions need adjusting and the stability of the segments will be lower.

Probabilistic CLV needs at least 18 months of history, ideally 24 months or more. The probabilistic models need enough customer history to learn the underlying distribution of purchase patterns. Below 18 months the models are unstable; above 24 months the predictions become reliable. For very mature businesses with five-plus years of data, the historical depth allows cohort-based validation: predict CLV for customers acquired five years ago using only their first three years, and check the prediction against the actual outturn. This validation builds confidence in the model for new customers.

RFM should be refreshed daily for mature implementations, weekly for starter implementations, monthly for the lowest-frequency businesses. The point is that customers move between segments continuously and the segmentation only stays useful if it stays current. A daily refresh in Fabric is simple to schedule. The marketing automation activation can pick up segment changes within hours of the customer's behaviour shifting. For B2B with monthly buying patterns, weekly refresh is usually sufficient.

The model should be refreshed monthly for active use, quarterly for stable settings. The underlying customer behaviour evolves over time, and the model parameters need refreshing to track the evolution. A monthly refresh in Fabric is straightforward to schedule. The output stays current, the limits stay calibrated, and the operational team trusts the numbers because they reflect current reality. Quarterly refresh is acceptable for businesses where the customer base is stable and the operational use is more strategic than tactical.

You should re-take the analytics maturity assessment annually as a sensible default. Quarterly if you are mid-way through a structured improvement programme and want to track progress. Less often than annually is too long: organisations change, environments drift, and a six-month-old score may not reflect today's situation. The assessment is short enough that the time cost is small. The clarity gain is meaningful.

AI governance needs ongoing attention, not just a one-off setup. As semantic models grow, new AI features are added, and usage patterns evolve, the same Model Trust review discipline needs to be reapplied periodically, not treated as a single sign-off at initial rollout.

Largely, yes — much of what is sold as AI in analytics is a rebranding of statistics. Most of what gets sold as AI in analytics today has been delivering value for decades under different names: machine learning, statistics, applied maths. RFM segmentation, market basket analysis, propensity modelling, time-series forecasting, anomaly detection, regression, clustering. All of these are AI in 2026 marketing language. Generative AI is genuinely new in the last three years. Agents combine both. The underlying technology lineage is older than the buzzword.

CLV is related to but different from customer profitability. Customer profitability is usually historical: what has this customer been worth so far. CLV is predictive: what will this customer be worth from this point forward. The two work together. Historical profitability tells you which customers have generated the most value to date. CLV tells you which customers will generate the most value in the future. The combination informs both retention (current most-valuable customers) and acquisition (target the profile that produces high CLV).

Copilot Studio is sometimes the right tool for an internal AI assistant. The right answer depends on what you actually need. Copilot Studio works for use cases that fit the conversational Q&A pattern with structured actions. For use cases that need deeper data analysis (better suited to Power BI Copilot grounded on certified models), agent-style automation (Power Automate plus targeted Copilot use), or custom application integration (better suited to Azure OpenAI direct), other tools are usually better. The Copilot Studio decision should follow the use case definition, not lead it.

Copilot is ready for mid-market production use for most use cases, with caveats by product. M365 Copilot and Power BI Copilot have matured meaningfully through 2024 and 2025; both are in production use across our client base. Fabric Copilot is younger but operational. Copilot Studio is genuinely in production for narrow custom use cases. The remaining caveat is universal: Copilot output quality depends entirely on the foundations underneath. Bad data plus Copilot is worse than bad data alone. Foundations first, Copilot second. The whitepaper covers this in detail.

Copilot is Microsoft's brand for the user-facing AI assistant layer. It sits on top of broader AI capability (Azure OpenAI, the Microsoft AI stack, machine learning) but most users only see the Copilot interface. When boards talk about 'doing AI', they usually mean Copilot. When data teams talk about 'doing AI', they usually mean the broader stack including ML and custom models. Both are valid; the distinction matters because the investment, the foundations, and the people involved differ. The AI, ML, Copilot and Analytics whitepaper covers the broader picture.

Yes — M365 Copilot data is secure, within the standard Microsoft commercial agreement. Your tenant data is protected from being used to train Microsoft's underlying models. M365 Copilot operates within the tenant's data boundary, with the prompts and responses subject to the same governance as the underlying M365 content. Sensitivity labels and Purview controls apply. The board is right to ask about data security; the answer is solid for the standard agreement. For specific data classifications requiring stronger controls, Purview adds the next layer.

RFM is usually enough on its own as a starting point, often complemented by additional segmentation dimensions later. RFM segments cover the core marketing decisions (acquisition, retention, reactivation, win-back) for most businesses. Layer on additional dimensions when specific decisions require them: demographic segmentation for targeted campaigns, behavioural segmentation for product recommendations, attitudinal segmentation for brand positioning. The pattern that works is RFM as the foundation with additional dimensions added on top, not RFM replaced by something more sophisticated.

Custom GenAI is not only for tech companies, although tech companies are the most active builders. Mid-market businesses across many sectors are building custom GenAI: legal firms building contract analysis tools, professional services building knowledge assistants, retailers building product description generators and recommendation chatbots, manufacturers building maintenance documentation assistants. The pattern is broader than the headlines suggest. The technical complexity has dropped enough that mid-market businesses with a clear use case can build production GenAI applications without needing a large engineering team.

Using AI agents that take actions on your behalf is safe only in narrow, well-defined, reversible use cases where the trust framework is strong. The cost of being wrong rises exponentially the moment an agent can act. An AI output that gets ignored is a wasted investment. An agent that takes the wrong action is a much bigger problem. 'If it cannot cite, it cannot conclude' applies tenfold to anything that can act. We approach action agents conservatively and expect the safe surface area to grow over the next twelve to twenty-four months as the trust frameworks mature.

Machine learning is genuinely useful for mid-market businesses, where the data foundations support it. ML works particularly well for pattern recognition tasks (segmentation, churn prediction, anomaly detection), forecasting (demand, sales, cash flow), and classification (lead scoring, content tagging, risk categorisation). The use cases that pay back are the ones with sufficient historical data to learn from and a specific decision the prediction informs. ML works less well as a vague aspiration without a defined problem. The pattern is to identify a concrete, repeated decision that better information would change, then build the ML on top.

Most organisations are probably not yet ready for AI, in the sense most leadership teams mean it. AI on bad data does not produce useful outputs. It produces confident-sounding rubbish at scale, faster than a human team could produce it manually. Most mid-market analytics environments need foundation work first: extracting data from legacy systems, building certified semantic models, governance, the trust framework. The largest part of most AI engagements is the work underneath the model, not the model itself.

Price and inventory optimisation is not a separately branded, standalone specialism - it is an extension of our existing machine learning and data science capability (already applied to demand forecasting, CLV modelling, and anomaly detection), built using the same Microsoft Fabric data science workload and modelling approach. We would rather describe it accurately as an extension of proven capability than imply a dedicated team exists that does not.

For a business new to machine learning, price and inventory optimisation is usually not the right starting point: we would generally recommend starting with core reporting and demand forecasting foundations first, and treating price and inventory optimisation as a next step once those are proven and trusted, rather than the first machine learning initiative attempted.

This is related to but distinct from the customer lifetime value and RFM work. CLV and RFM segmentation are about understanding customer value and behaviour; price and inventory optimisation are about product and stock decisions. In practice, customer segmentation often feeds into price optimisation (different price sensitivity by customer segment), so the two workstreams frequently connect.

Rolling out an AI use case follows three steps, in order — and skipping the order is the most common way pilots stall. First, inventory: know exactly what data the use case will touch, where it lives, who owns it, and what governance already applies to it, before any model or agent is built against it. Second, incremental deployment: launch to a small, defined group first, on a narrow use case, rather than the whole business at once, so a wrong output or a governance gap surfaces while it affects ten people rather than everyone. Third, deliberate human oversight: a defined point where a person reviews or approves the output before it reaches a customer or a financial decision, at least until the model's error rate is actually known rather than assumed. Businesses that treat this as a checklist to move through quickly are the ones that end up rolling an AI feature back shortly after launch. The sequence exists because each step surfaces problems the previous step could not have shown you.

For RFM in Fabric, use Python for most mid-market customer volumes (up to several million customers). Spark for genuinely large volumes (tens of millions of customers and beyond) where the parallelism matters. The Python implementation is simpler, faster to build, and easier for analysts to maintain. The Spark implementation is more scalable but adds complexity. Most mid-market RFM workloads do not need Spark; the Python version handles them comfortably on a Fabric Data Science notebook.

CLV should usually come after RFM. RFM is faster to build, easier to interpret, and the data foundations are usually less demanding. Most of our customer analytics engagements deliver RFM first to establish the baseline customer view, then layer on CLV to add the value dimension. The exception is businesses where the immediate commercial question is acquisition spend calibration, in which case CLV comes first because that is the question being asked. The right sequence depends on what the business needs to answer.

We generally recommend a phased rollout - starting with a defined group of trained users against a well-governed semantic model, rather than switching Copilot on organisation-wide immediately. This lets you observe how AI-generated answers are being used and trusted before scaling exposure.

Yes — you should de-duplicate customer records before RFM segmentation, where feasible. RFM produces noise when one customer is split across multiple records. The typical pattern in B2B is the same company appearing as separate accounts (parent group plus subsidiaries, multiple billing entities). The typical pattern in B2C is the same individual with multiple email addresses or repeated purchases as guest. The Silver layer in the lakehouse is where the unification happens. Sometimes the unification is automated (matching on email, phone, name and address); sometimes it requires manual reconciliation for the high-value records. The unification work is unglamorous but materially affects the quality of the RFM output.

You should usually not deploy M365 Copilot to everyone. The pattern that works in mid-market is targeted deployment to the roles where the productivity gain is highest, with expansion based on observed value. Common starting groups: leadership team (drafting and summary), commercial functions (drafting client communications, summarising research), HR and legal (document drafting and review), finance (analysis support). Universal deployment is expensive and often produces low usage in roles where Copilot does not match the work pattern. The targeted rollout is the more economical and observable starting point.

On whether to focus on Copilot or build custom AI, most boards are looking at Copilot. Most of the value in mid-market analytics today still sits in machine learning. The two are not in tension; they reinforce each other. A Copilot grounded on a churn prediction model is more useful than either component on its own. The honest answer is usually 'both, in sequence': foundations first, then a focused machine learning use case, then Copilot on top of governed content.

Whether to start with price optimisation or inventory optimisation depends on which decision currently causes more pain. Businesses with frequent stockouts or excess stock tying up working capital often get faster, clearer value from inventory optimisation first; businesses with more static pricing that has not kept pace with actual demand patterns often see more from price optimisation first. We help identify which is the higher-value starting point during discovery rather than assuming.

For most mid-market CLV implementations, use Fabric Data Science rather than Azure Machine Learning. The notebook environment is sufficient, the integration with the lakehouse is direct, and the operational overhead is low. Azure ML is the better choice when the CLV is part of a broader ML pipeline with sophisticated MLOps requirements, when the model retraining cadence is high, or when the model serving needs to be exposed as an API for real-time scoring. Most mid-market CLV use cases do not need Azure ML; the Fabric implementation is cleaner and cheaper.

For most analytics use cases, use Fabric Copilot. The integration is tighter, the governance is simpler, and the cost is bundled with the Fabric capacity you are already paying for. Azure OpenAI Service is the right choice for custom AI workloads outside the Fabric environment, for use cases needing direct API access to the underlying generative models, or for building custom AI applications that do not fit the Copilot interaction pattern. Most mid-market businesses do not need Azure OpenAI separately; Fabric Copilot covers the analytics use cases.

Use Fabric Data Science for most mid-market ML work. The advantage is integration: the data lives in OneLake, the notebooks run against it directly, and the trained models can be deployed back into Fabric for inference. The setup is simpler and the operating cost is lower than running a separate Azure ML environment. Azure ML is the better choice for very high-volume training, complex MLOps requirements, or model serving patterns that need dedicated compute. For the typical mid-market use case (segmentation, forecasting, churn), Fabric Data Science is sufficient and cleaner.

Yes — you should usually wait until your data foundations are ready first. The pattern of deploying Copilot before foundations are ready is the most common and most expensive failure mode. The licences cost real money, the capacity costs real money, and if the underlying data is inconsistent the outputs will not justify either. Better to delay Copilot for three to six months while the foundations are built than to deploy and have a high-profile failure that damages trust. We have written assessments recommending Copilot deferral; the recommendation costs us a Copilot rollout engagement and earns us trust for the foundation work.

Two organisations with the same total score can have completely different problems because the shape of the scores matters more than the total. An organisation scoring 3-3-1-2-1 has strong architecture and reporting but no governance and no adoption: targeted fixes needed. One scoring 2-2-2-2-2 is mediocre everywhere: a structured programme is needed. The first is a sharp problem in two specific places. The second is a broader capability gap. Same total, very different work to do.

The AI use cases that deliver value in mid-market analytics today are customer segmentation (RFM), cross-sell and upsell (market basket analysis), customer churn (propensity models), demand forecasting (time-series), anomaly detection, customer lifetime value, document analysis on contracts and RFPs, narrative summaries of dashboards, and Copilot-assisted authoring. Each works in specific conditions. None work in isolation. All depend on the same foundations: certified semantic models, governed data, years of historical data, the trust framework wrapped around outputs.

The Microsoft stack offers three main paths to ML capabilities. Azure Machine Learning is the dedicated ML platform with full lifecycle support: training, deployment, monitoring, and MLOps. Fabric Data Science is the Fabric workload for ML, with notebook-based development on top of OneLake data, suitable for most mid-market workloads without a separate Azure ML deployment. Azure OpenAI Service is the path to large language models for generative AI use cases. The right choice depends on the use case complexity and the team's existing skills.

Demand forecasting uses time-series models (ARIMA, Prophet) and gradient-boosted regression on historical sales. The output is a per-SKU per-period forecast with a confidence interval. Strong on stable products with several years of history; weaker on new product introductions, regime changes, and promotional volatility unless promotional history is captured cleanly. Demand forecasting is one of the highest-value mid-market ML use cases, particularly for retailers and consumer goods businesses where stock optimisation is a material lever.

Power Automate Generative Actions are AI steps you can drop inside an existing Power Automate flow - categorising incoming emails, extracting data from attachments, or drafting a response as part of an approval process. Rather than standing up a separate assistant, generative actions add reasoning inline, so an automation gains intelligence without being rebuilt around it.

There are five common RAG failure modes. Poor chunking that splits documents at unhelpful boundaries (mid-sentence, mid-table, separating closely related content). Retrieval that finds chunks topically related but not specifically relevant to the question. Context window overflow when too many chunks are retrieved. Hallucination when the foundation model fills gaps with plausible-sounding invention. Inadequate citation discipline so users cannot verify the source of generated answers. Each is preventable through deliberate engineering. The Trust Storytelling Delivery Checklist applies here particularly.

Embeddings are numerical representations of text (or other content) that capture semantic meaning in a high-dimensional vector space. Two pieces of text with similar meaning have embeddings that are close in vector distance, even if the actual words differ. Embeddings are the foundation of modern semantic search: instead of matching keywords, the system matches meaning. The embedding generation is done by specialised models (Azure OpenAI provides text-embedding-3-large and similar). Once generated, embeddings are stored in vector databases for fast similarity search.

RFM segmentation for B2B has three differences from B2C. The customer is usually an account, not a person, so the entity definition matters more. Frequency is naturally lower (B2B accounts buy less often than retail consumers), so the scoring boundaries differ. Monetary skew is usually higher (a small number of accounts dominate revenue), so the Monetary scoring needs careful boundary placement. The technique still works; the parameters adjust. We have implemented RFM for B2B distribution, professional services, and SaaS businesses with the same underlying approach as for B2C retail.

The biggest blockers stopping mid-market companies from adopting AI in their reporting are rarely the AI tool itself. In order of how often we see them: no senior owner who has actually decided what AI is for in the business, rather than a general sense it should be doing more of it; use cases picked because they were easy to demo rather than because they carry a quantifiable cost saving or revenue line; a governed data foundation that exists on paper but has not been tested against what an AI feature actually needs to query; no plan for keeping a model or agent running reliably once the pilot is over, so it works once and is never repeated; and no view on what happens to internal trust if the first pilot underperforms. The businesses that get past this treat AI readiness as a distinct piece of work that comes after data governance, not a feature they bolt onto it.

There are four components of a RAG system. A knowledge source (documents, database records, structured data) containing the information the system can reference. An indexing pipeline that processes the knowledge source into searchable form, typically by splitting documents into chunks and converting each chunk to a vector embedding. A retrieval engine that finds the most relevant chunks for a given query, usually through vector similarity search. A generation step that includes the retrieved chunks in a prompt to the foundation model and produces the final answer. Each component has design choices that materially affect quality.

The five layers of the Microsoft AI stack are capacity (Fabric, F2 to F2048): the compute that powers everything else. Data (OneLake, lakehouses, warehouses, certified semantic models): where data lives and what makes outputs trustworthy. Models and ML (Azure Machine Learning, Fabric Data Science, Azure OpenAI): the build-your-own paths. User-facing AI (Copilot in Power BI, Fabric, M365, Copilot Studio): the visible layer. Governance (Microsoft Purview, RLS, Copilot Connectors): the control layer. Take any layer away and the whole thing breaks.

There are three main approaches to calculating CLV. Historical CLV: sum the past revenue or margin per customer over a defined period. Simple predictive CLV: extrapolate historical patterns forward using assumed retention rates and average order values. Probabilistic CLV: statistical models (BG/NBD, Pareto/NBD, Gamma-Gamma) that predict future purchase frequency and value per customer based on individual customer behaviour. Each has its place. Most mid-market businesses start with simple predictive and move to probabilistic when the data and team support it.

The standard RFM segments are eleven segments that cover most businesses well. Champions (high R, F, M). Loyal customers (high F, M). Potential loyalists (high R, mid F). New customers (high R, low F). At-risk (low R, high F, M, indicating valuable customers slipping). Cannot lose them (very low R, very high M). Hibernating (low R, low F, mid M). Lost (very low R, low F, M). About to sleep (declining R, mid F, M). Promising (high R, low M, indicating new with potential). Need attention (mid R, F, M, the middle group). The segment count and naming varies by business; the underlying pattern is consistent.

There are five strongest use cases for custom GenAI in mid-market. Customer service assistants grounded on product knowledge and customer history. Internal knowledge search across company documents, policies, and procedures. Document analysis and summarisation for contracts, RFPs, and reports. Sales enablement assistants that surface relevant case studies and product information for sales reps. Content generation for marketing, product descriptions, and structured communications. The use cases that pay back have defined audiences, defined tasks, and clear success measures. Vague aspirations (we want AI) without defined use cases consistently produce disappointing outcomes.

Three failure modes that destroy trust in AI outputs more than any others. AI Said So: confident outputs with no evidence trail. Silent Changes: the model produces a different recommendation later and nobody can explain why. Pocket Failures: the model is right on average but wrong in the segments that matter most. The framework is Nick Kelly's. Once you have seen them named, you start spotting them everywhere.

The three patterns for AI agents are monitoring agents: watch data continuously, flag anomalies, route to humans for action. Lowest risk, deployable today. Retrieval agents: surface information across systems without acting. Useful for internal Q&A and customer service support. Action agents: execute well-defined tasks like placing orders or sending emails. Highest risk, highest reward. Only safe in narrow, reversible use cases where the trust framework is strong. Treat the three as separate categories, not one.

AI-augmented analytics can today do concrete, useful things: generate charts and measures from a plain-language prompt, detect and flag anomalies, suggest the likely root cause of a change, and summarise what a report shows in words. In the Microsoft stack, Copilot in Power BI and Fabric brings much of this into familiar tools. The right framing is acceleration, not autonomy — it shortens the path from question to answer and reduces reliance on scarce data-science skills, but does not replace human judgement.

Profile B (Tool-Rich, Governance-Poor) is characterised by Power BI being in use, with dashboards and reports that exist - but so do 150 reports nobody maintains, three definitions of revenue, and no naming conventions. Content scattered across personal workspaces. Nobody knows what is current and what is stale. Priority: governance. Establish naming conventions, workspace structure, and ownership. Rationalise existing reports (you probably need a third to half as many as you have). Then build a proper semantic model as the single source of truth.

The Single-Person Dependency profile is characterised by one person having built everything. They know the data, the models, the reports, and the workarounds. The business has good analytics but it all sits in one head. If that person leaves, gets ill, or goes on holiday, the capability disappears. Priority: reduce the bus factor. Document the data models, train at least one other person, consider structured external support to build resilience.

You need three things before starting ML work. Years of historical data on the relevant subject (transactions, customers, products, operations). Clean, certified semantic models so the data the ML reads is consistent. Defined decisions the ML predictions will inform. The data volume is rarely the constraint at mid-market scale; the data quality and the certified definitions are. Most failed ML investments we see are downstream of unresolved data quality issues. Cleaning the foundations is unglamorous but is the largest single factor in whether ML pays back.

CLV needs customer transaction history with three pieces of information: customer identifier, transaction date, and transaction value. The same minimum dataset as RFM. For more sophisticated models, additional data helps: customer attributes (demographics, segments), product mix per transaction, channel and source, contract terms for subscription businesses. The minimum dataset produces a working CLV; the richer dataset produces a more accurate one.

RFM segmentation needs three columns at minimum: customer identifier, transaction date, and transaction value. That is it. The technique does not need demographic data, marketing engagement data, or product-level detail to produce useful segments. Any business with a customer-tagged transaction history can build RFM. The minimal data requirement is why RFM is often the first analytical technique deployed in mid-market businesses; the foundation is usually already in place.

Inventory optimisation needs historical demand data, current lead times from suppliers, holding cost assumptions, and a defined service level target (how often you are willing to accept a stockout versus how much excess stock cost you are willing to carry to avoid one). Getting the service level target genuinely agreed with the business, rather than left as a technical assumption, is one of the most important and most often skipped steps.

Price optimisation needs sufficient historical sales data across enough price points and time periods to observe how demand actually responds to price changes, ideally alongside competitor pricing data and product cost data. Where historical price variation has been minimal (prices have barely changed in years), there may not be enough signal in your own data to model elasticity reliably without external market data.

Five dimensions determine whether a business is actually AI-ready, and they rarely move at the same pace inside one business. Data quality: whether the specific data an AI feature needs is complete and reliable, not whether data exists somewhere in the business. Governance: whether a framework for classification, lineage and access already exists for an AI feature to plug into safely. Infrastructure: whether the platform can actually serve a model or agent reliably in production, not just run it once in a notebook. Talent: whether someone inside the business can maintain and improve the thing after a consultancy leaves, not only build it in the first place. Leadership alignment: whether a senior owner has actually decided what the AI investment is for, with a cost saving or revenue line attached, rather than a general ambition to do more with AI. Most businesses are strong on one or two of these dimensions and weak on the rest, which is exactly why our AI Readiness Assessment scores all five explicitly rather than assuming strength in one implies readiness generally.

For business analytics, responsible AI means being able to answer, with confidence, where an AI-generated number or answer came from, whether it is grounded in your governed data, and what happens when it is wrong. It is less about abstract AI ethics principles and more about the practical question of whether a business user can trust a Copilot-generated answer or an AI-written narrative enough to act on it.

AI does not replace the consultants and analysts. The repeatable, well-defined, high-volume work that has historically consumed most of an analyst's week: pulling data, drafting reports, spotting anomalies, producing first-pass forecasts. AI does this fastest and best. What AI does not do is judgement: deciding which question matters, calibrating a recommendation against organisational context, defending a number to a board. The organisations getting the most out of AI are using it to free expertise from the work that did not need it.

Copilot Studio uses a per-message consumption model on top of a base licence. The economics are reasonable for narrow high-value use cases (a customer service Copilot reducing call centre volume) and questionable for broad low-value use cases (a general-purpose internal Copilot replacing intranet search). The right pricing question is the cost per resolved query compared to the alternative; not the headline message rate. The economics depend heavily on use case design.

Copilot delivers value in mid-market in three main patterns. Productivity gains for individual knowledge workers (drafting, summarising, Q&A across documents). Faster authoring for technical users (DAX, queries, pipeline code). Conversational access to certified semantic models for business users querying their own data. The pay-back is typically time saved per user per week, multiplied across the relevant audience. The use cases that pay back fastest are the ones with high-volume repetitive cognitive tasks; the ones that pay back slowest are the ones where the existing process was already efficient or where the foundations are not ready.

Fabric Copilot helps with code generation, SQL queries, KQL for real-time analytics, notebook code, and pipeline development inside the Microsoft Fabric workloads. Useful for capable engineers who want to accelerate routine code; risky for users who cannot evaluate the output. The capability is similar in spirit to GitHub Copilot for software engineering: a productivity multiplier in the right hands, a source of plausible-looking errors in the wrong ones. Fabric Copilot makes most sense for the data engineering team, less so for business users.

On AI engagements, Hopton delivers data foundations for AI (the largest part of most engagements), customer analytics models (RFM, MBA, churn, CLV, propensity), forecasting and demand models, anomaly detection, Copilot deployment on top of certified semantic models, document analysis pipelines, monitoring and retrieval agents on governed data, and the trust framework integration that makes the outputs decision-grade. Most engagements span several of these. Foundations first, then a focused use case, then expansion.

M365 Copilot specifically drafts content in Word, summarises documents and emails, creates PowerPoint decks from prompts, builds Excel formulas and analysis from natural language, summarises Teams meetings and chats, drafts replies to emails. The capability is broad and the depth varies by application. Strongest in Word (drafting and editing) and Outlook (summary and reply); developing in Excel (analysis is real but limited compared to dedicated BI); useful in Teams (meeting summary is genuinely valuable); variable in PowerPoint (the deck generation works but rarely produces something publishable without significant editing).

Microsoft 365 Copilot costs around £24.70 per user per month at the time of writing, on a per-user licence separate from any Fabric capacity or other Microsoft licensing. A 200-person organisation deploying M365 Copilot to half its staff is looking at roughly £30,000 per year in licences alone. The unit cost is straightforward; the harder question is which users get a licence. It pays back fastest for users who write a lot (executives, sales, marketing, HR, legal) and slowest for users whose work is mostly reading and meetings, so it is worth assessing per role rather than rolling out organisation-wide.

Power BI Copilot requires a Fabric capacity at F2 or higher, since April 2025. Before April 2025 the minimum was F64 (around £6,400 per month), which priced out most mid-market organisations. The change to F2 (around £200 per month) put Power BI Copilot within reach of any organisation already using Fabric for analytics. The Fabric capacity covers all Fabric workloads, not just Copilot, so the cost is more accurately attributed across the platform than to Copilot alone.

Power BI Copilot helps authors create visuals from natural language descriptions, generates DAX measures from prompts, drafts narrative summaries of report content, and answers questions about the data in a semantic model conversationally. The most useful capability for authors is DAX generation; the most useful capability for consumers is the conversational Q&A. Both work well when grounded on certified semantic models. Both produce confident-sounding errors when grounded on inconsistent or uncertified data, which is why the foundations matter so much.

A Copilot implementation involves three workstreams. The technical workstream: licensing, capacity, configuration, and integration with the M365 or Fabric environment. The data foundations workstream: certified semantic models, governance, sensitivity labels, the work that determines whether Copilot output is trustworthy. The adoption workstream: training, change management, the Trust Storytelling Delivery Checklist, and the measurement of Decision Adoption Rate. Most failed Copilot rollouts skip the second or third workstream and find out later why those mattered.

An ML engagement involves five phases. Use case definition (what specific decision will the ML inform, what is the cost of being wrong). Data exploration and feature engineering (what data is available, what features predict the target). Model development (training, evaluation, tuning). Deployment (putting the model into production with the inference pipeline). Monitoring (tracking model performance over time and triggering retraining when needed). The total timeline for a first useful ML deliverable is typically 8 to 16 weeks depending on data readiness. Subsequent use cases are faster because the foundations carry over.

For an AI answer to be grounded, it means the AI is constrained to draw its answer from a governed, certified data source - a semantic model with agreed metric definitions and proper security applied - rather than reasoning freely or inferring an answer from an ungoverned or partial view of your data. A grounded answer to "what was our revenue last quarter" should be traceable back to the same certified dataset every report on revenue already uses.

The Adoption dimension of the analytics maturity model measures whether people actually use data to make decisions. The dimension that matters most and the one most often ignored. Level 1: reports exist but few people look at them. Level 3: data-informed decisions are the norm, people pull up dashboards in meetings, challenge assumptions with evidence, and trust the numbers enough to act. Adoption is a habits problem, not a technology problem. You can have perfect everything else and still fail here.

The Governance dimension covers the rules, ownership, and controls around your data and analytics: naming conventions, access controls, data ownership, change management, and accountability for quality. Level 1 has none of these formally. Level 3 has a clear, lightweight framework everyone follows: naming standards, workspace structures, defined data owners, and a process for promoting content from development to production. Governance is almost always the lowest-scoring dimension we see.

The Power BI semantic model is a standard star schema with one addition. The Customer dimension carries the latest RFM scores and segment assignment as columns. The Sales fact records every transaction. The model needs a Date dimension covering the analysis period plus the lookback window. Two or three calculated tables hold the percentile thresholds (the boundaries between scores). DAX measures calculate live RFM scores as the user changes the date filter, which is the killer feature: RFM as of any historical point, not just today.

The Reporting dimension of the analytics maturity model measures the quality, consistency, and usefulness of your reports and dashboards. Whether reports are trusted, whether they agree with each other, and whether they actually inform decisions. Level 1 is ad hoc and request-driven, with different reports giving different answers. Level 3 is a governed set of reports built on trusted semantic models that the business uses as a matter of course.

The Skills dimension of the analytics maturity model measures the analytical capability in your organisation. Whether you have people who can build and maintain reports, whether they have the right tools and training, and whether the organisation depends on a single person. Level 1 is everything depending on one person, or fully outsourced with no internal knowledge. Level 3 is a cross-functional team with defined roles, ongoing development, and enough depth that the departure of one person does not bring the whole thing down.

The customer lifetime value (CLV) output is per-customer CLV estimates over a defined prediction horizon, with confidence intervals. A typical output table contains customer ID, predicted purchases over the next 12 months, predicted average order value, predicted CLV (purchases times value times margin), and a confidence interval around the prediction. Aggregate views show CLV distribution across the customer base, CLV by segment, and CLV by acquisition cohort. The output supports both individual-customer decisions and aggregate strategy decisions.

The data flow for a customer lifetime value model starts at the Bronze layer, which captures raw transaction data. Silver cleans and aggregates to customer-level transaction history. Gold contains the customer-transaction view ready for the model. The CLV notebook reads Gold, fits the models, generates per-customer predictions, and writes a CLV Delta table. Power BI semantic models read the CLV table alongside the customer and sales data. The architecture is the standard Bronze/Silver/Gold pattern. The CLV is one of several customer analytics outputs sitting at the Gold layer.

Each block of the Model Trust One-Pager captures one thing, starting with the Decision: what specific decision this output is supposed to inform, and who acts on it. Sources: which systems, tables, and date ranges fed the output. Freshness: when the data was extracted, when the model was retrained, when the output was produced. Limits: where the model is weaker and where the recommendation should be ignored. Confidence: honest calibration, not just self-reported probability. Recommended action: specific, time-bound, named owner. Change history: what changed since the last version.

Copilot rollouts go wrong in three patterns we see repeatedly. Deploying Copilot to weak foundations, where the underlying data is fragmented or uncertified, producing confident-sounding outputs that should not be trusted. Universal licence rollout without targeted use case definition, producing low usage and high cost. Treating Copilot as a tool to deploy rather than a capability to adopt, neglecting training and change management. Each is preventable. The whitepaper covers the trust framework that prevents the first; this FAQ covers the implementation patterns that prevent the second and third.

RFM implementations go wrong in five recurring patterns. Weak customer deduplication producing noisy segments. Too many segments producing groups too small to act on (eleven is plenty). Over-customised segment names that confuse stakeholders rather than illuminating. Static segments that never get refreshed, drifting from reality over months. Segments built but never activated in the marketing or CRM workflow. Each is recoverable. The first two surface during the build; the others surface in the months after launch and require ongoing attention.

Messy or fragmented historical data is a common starting point. The cleansing and consolidation work in the Silver layer of the lakehouse is part of every ML engagement. It is more work than the modelling itself; the modelling techniques are well-known, the data preparation is where the engineering effort concentrates. Treat the data foundation work as the precondition for ML rather than as something to skip. Clients who try to skip it discover the hard way that bad data plus ML produces worse outcomes than bad data alone, because the ML adds confidence to the wrong answers.

A previous machine learning investment that did not deliver is a common situation. Most failed ML investments are recoverable with the right framework. The honest assessment usually shows that the technology worked but the trust framework was missing, the data foundations were inadequate, or the use case was poorly defined. We have rebuilt failed forecasting models and abandoned classification work using the same underlying technology with the foundations corrected. The relaunch is usually faster and lighter than the original because the lessons are visible.

Disagreement on the maturity assessment score is the most valuable finding. Where the IT director, the finance director and the managing director disagree on a dimension is where the conversation needs to happen. It usually means people have different views on what 'good' looks like, or different levels of visibility into the actual environment. Both are useful to surface. Run the assessment independently, then compare and discuss.

Losing historical data after a CRM or ERP change is a common situation, and a recoverable one. The right approach is usually to start RFM on the available data with a short recency window (months rather than years), accepting that the segments will be less stable initially, and to track the evolution as more data accumulates. The other recoverable path is to source the missing data from invoicing or finance archives that often outlive CRM migrations. Some of our most useful RFM implementations have been on businesses that thought they had lost the history but had it sitting in invoice data.

AI Builder is a Power Platform feature that adds pre-built AI models - document and invoice processing, sentiment analysis, object detection, text classification - directly into Power Apps or Power Automate. There's no need to write code or provision infrastructure; you plug a trained model into your app or flow. It suits well-defined, narrow tasks rather than open-ended reasoning or multi-step orchestration.

Azure AI Foundry is Microsoft's platform for building, evaluating, and deploying AI applications. Azure AI Foundry provides a unified workspace combining model access, prompt flow design, evaluation tooling, and deployment options. For mid-market businesses building several GenAI applications, Azure AI Foundry is the operational platform that makes the development workflow manageable. For single one-off applications, direct API access to Azure OpenAI may be sufficient. The decision depends on the breadth of GenAI ambition rather than the depth of any single application.

Azure OpenAI Service is Microsoft's hosted version of OpenAI's foundation models (GPT-4, GPT-3.5, embeddings, DALL-E) running in Azure with enterprise-grade security, governance, and SLAs. Azure OpenAI gives you direct API access to the models for building custom applications. The advantages over using OpenAI directly include data residency in Azure, integration with Azure identity and security, enterprise SLAs, and contract terms compatible with most enterprise procurement. For Microsoft-stack businesses, Azure OpenAI is the right default for foundation model access.

BG/NBD and Gamma-Gamma is the current standard probabilistic approach for non-contractual customer relationships (most retail, ecommerce, hospitality). BG/NBD (Beta-Geometric / Negative Binomial Distribution) predicts future purchase frequency per customer based on their historical purchase pattern. Gamma-Gamma predicts the average purchase value per customer. The two combined produce a CLV estimate per customer. The maths is well-established and there are mature Python libraries (lifetimes is the standard) that implement the models cleanly. The output is rigorous in a way the simpler approaches are not.

Copilot Studio is the platform for building custom Copilots on your own data, workflows, and actions. The use cases include internal HR or IT support bots, customer-facing Copilots embedded in your own applications, and specialist assistants that combine knowledge from multiple sources. Copilot Studio is genuinely useful for narrow well-defined use cases. It is easy to overscope: clients build broad ambitions and end up with a chatbot. The use cases that succeed are tightly defined; the ones that fail are vaguely defined.

Data Architecture, in this context, is where your data lives, how it gets there, and whether it is structured for analysis. Source systems, data pipelines, storage, and the degree to which your data is unified or scattered. Level 1 is spreadsheets and manual extracts. Level 3 is data flowing automatically from source systems into a structured platform, stored once, and accessible to anyone who needs it.

Microsoft Copilot, in plain English, is a family of AI assistants built into Microsoft products. M365 Copilot lives inside Word, Excel, PowerPoint, Outlook, and Teams, helping users draft, summarise, and analyse content. Power BI Copilot lives inside Power BI, helping authors create visuals and DAX from natural language. Fabric Copilot lives inside Microsoft Fabric, helping with code generation, query writing, and pipeline development. Copilot Studio is the platform for building custom Copilots on your own data and workflows. They share the same underlying generative AI technology but serve very different audiences.

RFM segmentation is a customer segmentation technique that scores each customer on three dimensions: Recency (how recently they bought), Frequency (how often they buy), and Monetary value (how much they spend). Each dimension is scored on a scale, typically 1 to 5, producing a three-digit code per customer. The codes group into recognisable segments (champions, loyal customers, at-risk lapsers, new customers, hibernating customers, lost customers) that drive marketing, retention, and clienteling decisions. RFM has been used in direct marketing for over 50 years and remains one of the most reliable segmentation techniques because it works on transaction data alone, without behavioural or attitudinal data.

A vector database is a database optimised for similarity search on high-dimensional vectors. The dominant choice for Microsoft-stack applications is Azure AI Search, which provides vector search alongside traditional keyword and semantic search. Azure Cosmos DB also supports vector search. Specialist vector databases (Pinecone, Weaviate, Qdrant) offer additional features for complex use cases. For most mid-market RAG implementations, Azure AI Search is the right default: integrated with the Microsoft stack, performant, and operationally manageable.

Microsoft Copilot is the productised generative AI assistant embedded in Microsoft applications (Word, Excel, Power BI, Fabric, Dynamics). Custom generative AI is bespoke applications built on top of foundation models (GPT-4, Claude, others) for use cases that Copilot does not cover. Custom GenAI applications are built on Azure OpenAI Service, Azure AI Foundry, and the broader Azure AI ecosystem. The choice between Copilot and custom is rarely either-or; many businesses use both, with Copilot for the productised use cases and custom solutions for specific workflows.

Customer lifetime value is an estimate of the total value a customer will generate for the business over the duration of the customer relationship. CLV is forward-looking by definition: it predicts future value, not past value. The headline number is per-customer or per-cohort, expressed in currency and discounted appropriately for time. CLV is one of the highest-leverage analytical outputs in customer-focused businesses because it informs acquisition spend (how much you can afford to pay for a new customer), retention prioritisation (which customers are worth keeping), and segmentation (which customer groups deserve disproportionate investment).

Inventory optimisation goes beyond forecasting: where demand forecasting predicts how much of something you are likely to sell, inventory optimisation goes a step further and recommends how much stock to hold and when to reorder, factoring in lead times, holding costs, service level targets, and demand uncertainty - turning a forecast into an actual stocking and replenishment decision.

Price optimisation uses historical sales, demand elasticity, and competitor or market data to recommend prices that improve a target outcome - typically margin, volume, or a blend of both - rather than relying purely on cost-plus or competitor-matching rules. It is a modelling discipline built on top of the same demand and transaction data that already feeds standard sales and margin reporting.

Retrieval-augmented generation (RAG) is an architectural pattern where a generative model is augmented with retrieval from a knowledge source at query time. The flow: a user asks a question, the system retrieves relevant context from a document store or database, the context is included in the prompt, and the model generates an answer grounded on the retrieved context. RAG is the dominant pattern for building question-answering systems on private knowledge because it lets generative models work with domain-specific data without fine-tuning.

The AI Readiness Assessment is a four-week, fixed-scope, fixed-price engagement. Week one: discovery of your data foundations and the decisions AI is supposed to inform. Week two: gap analysis between current state and AI-readiness. Week three: two or three costed AI use cases, each with a Model Trust One-Pager already drafted. Week four: written recommendation including, when appropriate, the recommendation to defer AI investment until foundations are in place. No obligation to continue with us afterwards.

The AI Said So failure mode is when an AI output appears with confidence and no evidence trail. The recommendation is clear, the language is decisive, and there is no way for the recipient to check what it is based on. They cannot tell what data was used, how recent it is, what was excluded, or what assumptions are baked in. The rational response, and the one we see almost universally, is to ignore the output. Once that has happened, the credibility damage extends to everything downstream.

The Good Foundations, No Adoption profile is strong architecture, solid reports, clear governance. Nobody uses any of it. Decisions are still made the way they always were. The investment in data and analytics has not changed any behaviour. Priority: adoption is not a technology problem. Embed reports into existing meetings. Make the data relevant to the people being asked to use it. Get leadership to model the behaviour. Stop building new dashboards and start getting value from the ones you already have.

The Model Trust One-Pager is a single page, structured into seven blocks, that sits alongside any AI output going into a decision. The seven blocks are: the decision, sources, freshness, limits, confidence, recommended action, and change history. It travels alongside the AI output, not in an audit log buried somewhere else. The stakeholder receiving the output sees both at once. Everything they need to act safely is on the page in front of them.

The Pocket Failures failure mode is when the model is right on average. It performs well in tests. The accuracy metric looks strong. But it is wrong in the exact segment that matters most: the high-value customers, the new store format, the region with different behaviour. Stakeholders remember pocket failures forever. A model that is ninety-two per cent accurate overall but wrong about the top ten customers will be remembered as the model that got the top ten customers wrong.

The Silent Changes failure mode is when the model produces a recommendation in March. It produces a different recommendation in June. Nobody can explain why. The training data shifted, or a parameter was tuned, or a feature was deprecated, but the change happened silently. The first time, the stakeholder questions the model. The second time, they question the team running it. By the third, they have stopped engaging entirely. The fix is not to stop changing models. It is to make every change visible, dated, and explained.

The biggest risk of rolling out Copilot or GenBI features without a governance plan is users trusting AI-generated answers more than they should, simply because the answer is confidently phrased and appears instantly. Left unmanaged, this can quietly reintroduce the same "whose number is right" problem that governed BI was supposed to solve, just with an AI layer providing false confidence on top.

The difference between ML, AI, and predictive analytics is that ML and predictive analytics are largely the same thing under different names. AI is the broader category that includes ML, generative AI (large language models), and agent systems. Most of what people in mid-market call AI today is actually ML, and most of what they call predictive analytics is also ML. The distinctions matter for marketing more than for delivery. We use 'machine learning' to mean the statistical and pattern-recognition techniques that have been delivering value in analytics for decades, regardless of whether the marketing wraps them as AI.

The difference between being data-ready and being AI-ready is a clean, governed data estate is necessary for AI, but it has never been sufficient on its own. Data readiness means your data is centralised, accurate, and reliably refreshed. AI readiness adds three further things on top: a semantic layer that AI tools can query without ambiguity, governance that extends to AI-generated outputs and not just human-built reports, and clearly defined use cases with a way to measure whether the AI is actually right. Most organisations we assess have decent data readiness and weak AI readiness, and that gap is where most AI projects stall, not in the data pipeline itself. We built a free, 8-question AI Data Readiness Checker so you can see roughly where your organisation sits before committing budget to an AI project.

The difference between data storytelling and trust storytelling is that data storytelling explains what the numbers say. Trust storytelling makes the decision safe to take. The industry has spent a decade teaching the first one and largely ignoring the second. A stakeholder sitting in a meeting is not thinking 'I do not understand this chart'. They are thinking 'if I act on this and it is wrong, I am the one holding the bag'. Trust storytelling answers the second question. The framing is owed to Nick Kelly, whose work shaped much of how we approach AI in analytics.

Fine-tuning, RAG, and prompt engineering are three different approaches to making foundation models work for specific use cases. Prompt engineering is the discipline of writing effective prompts that elicit good responses from the base model. RAG (retrieval-augmented generation) provides relevant context to the model at query time by retrieving relevant documents and including them in the prompt. Fine-tuning trains a custom version of the model on your specific data and use case. The three are not mutually exclusive; sophisticated applications use all three. For most mid-market use cases, prompt engineering plus RAG is sufficient and significantly cheaper than fine-tuning.

The single operating rule for AI outputs is: if it cannot cite, it cannot conclude. Nick Kelly's shortest version of the trust framework. If an AI output cannot cite where its evidence came from, it is not allowed to conclude anything. It can produce a draft, raise a flag, suggest a hypothesis, but it cannot make a recommendation that anyone is expected to act on. This rule does most of the heavy lifting. It rules out almost every AI Said So failure and forces the data lineage that prevents Silent Changes.

The typical pay-back timeline for ML investment is six to twelve months for the first useful output, with full pay-back depending on the use case. Demand forecasting often pays back in stock optimisation savings within the first year. Churn prediction pays back in retention spend efficiency within months. Customer lifetime value modelling pays back in marketing spend optimisation over a longer horizon. The pay-back depends on the size of the decision the model informs and the precision of the prediction. Small decisions made many times pay back fastest; large decisions made occasionally pay back slowest.

Five kinds of business benefit most from RFM. Retail with repeat customers (loyalty programmes, ecommerce, multi-purchase categories). Subscription and recurring-revenue businesses (where Frequency captures engagement). B2B with repeat purchases (wholesale, distribution, professional services with retainer or repeat work). Ecommerce of any kind. Hospitality and leisure businesses with repeat visitation. RFM works less well for one-off-purchase businesses (large capital purchases, infrequent services) where Frequency loses meaning.

On the analytics maturity model, you should fix your lowest-scoring dimension first, almost always. Analytics capability is limited by its weakest link. As a general rule: governance below Level 2 should be fixed before anything else, because without governance every other investment creates mess. Data architecture at Level 1 needs structured data foundations. Reporting at Level 1 needs a small number of trusted reports on a proper semantic model. Skills at Level 1 needs at least one person who can maintain the environment. Adoption at Level 1 is a people problem.

Price and inventory optimisation is a realistic fit for businesses with enough transaction volume and history to model demand elasticity or stock behaviour meaningfully — typically retail, wholesale, FMCG, and manufacturing businesses with established sales data, which overlaps closely with our existing sector base. A business with very low transaction volume or highly irregular, one-off sales is a poor fit for this kind of modelling regardless of who builds it.

What stops teams adopting AI in analytics is rarely the technology. The real blockers are governance and trust — people won’t act on numbers they can’t verify — plus fragmented systems and inconsistent KPIs that make AI answers unreliable, privacy and auditability concerns in regulated settings, and human factors like change resistance, missing training, and hard-to-prove ROI. The fix is governed, consistent data and clarity on which decisions the tools support, not buying more AI.

Before using Copilot or GenBI features, business users need training on what the AI feature is (and is not) grounded in, how to recognise when an answer looks wrong, and where to check a number before acting on it, alongside the standard report training. Treating AI features as something users can safely explore without any guidance tends to produce over-trust faster than under-trust.

The difference between being data-ready and being AI-ready is that data readiness is about whether you manage and trust your data: governance, quality, integration, security and a clean architecture. AI readiness is a separate, harder question sitting on top of that: can you actually deliver and scale AI in a way people are willing to act on. That covers senior ownership of what AI is for, use cases chosen because they carry a real cost saved or revenue line rather than because they demo well, the engineering work to keep a model running reliably rather than just working once in a notebook, risk and responsible-AI guardrails, and whether your teams have the literacy to trust and use what gets built. Most stalled AI pilots we see did not fail because the data was bad. They failed because a clean, governed data estate was mistaken for the whole plan, when it is only the first of several foundations that need to be in place.

Power BI alone stops being enough at three triggers. Customer volumes above a few hundred thousand make the DAX performance challenging. Need for time-series RFM (segment evolution per customer over months) exceeds the DAX-friendly scope. Integration with marketing automation requiring customer-level segment assignments delivered as data feeds rather than reports. Past these thresholds, the implementation moves to Fabric Data Science or Azure ML with the segments materialised in the lakehouse and surfaced in Power BI for reporting.

When customer-level CLV matters for the business decisions, when the customer base is heterogeneous (different customers behave very differently), and when the analytical capability is in place. Probabilistic CLV produces per-customer estimates rather than averages, which lets retention and segmentation decisions be made at the individual level rather than the cohort level. The implementation is more involved but the operational value is materially higher for businesses that genuinely use the customer-level numbers.

Power BI Copilot is worth deploying when the underlying semantic models are certified and the data is governed. The capability is genuinely useful in those conditions: authors save material time on DAX and visual creation, consumers can ask questions of the data without authoring skills, and adoption rises because the friction drops. The capability is harmful in the absence of governed data: Copilot produces confident-sounding answers from data that does not consistently mean what users think it means, and trust erodes quickly. Foundations first is the correct sequencing.

Custom GenAI is worth building rather than using Copilot in five patterns. Customer-facing AI features in your own product or website. Internal AI applications grounded on data that does not fit Copilot's expected sources. Specific workflow automation that needs deeper integration than Copilot Studio supports. Domain-specific assistants where the foundation model needs careful prompting and grounding for the specialist context. AI features for unique business processes that have no productised equivalent. Outside these patterns, Copilot products usually cover the need at lower cost and complexity.

Simple predictive CLV is good enough when you need a working number quickly, when the customer base behaves homogeneously, or when the audience for the CLV is more interested in the magnitude than the precision. A simple formula (average revenue per customer per year times average customer lifespan times margin percentage minus acquisition cost) produces a single CLV figure that informs acquisition spend decisions. The number is approximate but defensible. For most mid-market businesses early in their analytics journey, simple predictive CLV is the right starting point.

Microsoft's prebuilt Azure AI (cognitive) services are useful for specific tasks. Microsoft's prebuilt AI services cover text analytics (sentiment, key phrase extraction), document intelligence (extracting data from invoices and forms), translation, computer vision, and speech-to-text. For these specific tasks, the prebuilt services are usually faster and more accurate than building custom models, particularly for mid-market scale. The decision is custom model versus prebuilt service, on a use case by use case basis. Many of our ML engagements combine custom models for the unique business logic with prebuilt services for the commodity tasks.

You can see the full AI guide on hoptonanalytics.com under Resources. The guide is the capstone of the Hopton Insight Series and covers the trust framework in detail, the three Trust-Killers, the Model Trust One-Pager with a worked example, the Microsoft AI stack, Copilot pricing in detail, the three agent patterns, and how the foundations described in the rest of the series determine whether AI investment pays back. To discuss a specific situation, email hello@hoptonanalytics.com.

The full analytics maturity guide and the assessment are on hoptonanalytics.com under Resources. The guide explains each dimension and level in detail, the five profiles in depth, and what to fix first. The assessment itself fits on a single page and takes fifteen minutes. To discuss your score, email hello@hoptonanalytics.com.

CLV pays back most in five business shapes. Subscription and recurring-revenue businesses where customer relationships extend over years. Ecommerce with repeat customers where acquisition cost decisions are material. Retail with loyalty programmes or strong repeat patterns. B2B with customer concentration and long relationships. Professional services with retainer or repeat-engagement work. CLV pays back less in one-off-purchase businesses (large capital purchases, infrequent services) where the lifetime is short. The technique is most valuable where the lifetime is long enough for the predictive horizon to matter.

RFM is usually one of the early ML-style outputs to deliver after the data foundations are in place. It works on transaction data alone, the implementation is fast, the output is immediately actionable, and the value is visible. Many of our engagements include RFM as one of the early deliverables in the Build phase, with more sophisticated techniques (CLV, churn prediction, market basket analysis) following once the customer analytics foundations are stable.

Five recurring ML use cases pay back fastest in mid-market. Customer segmentation through RFM (recency, frequency, monetary value) analysis. Churn prediction for subscription, recurring-revenue, or repeat-purchase businesses. Demand forecasting for stable products with several years of history. Anomaly detection for operational and financial irregularities. Customer lifetime value modelling for businesses where acquisition cost decisions are material. Each is well-established, each has predictable data requirements, and each has clear use cases where the prediction changes a specific decision.

For RFM segmentation, use Pandas for the data manipulation, NumPy for the numerical work, and scikit-learn for the percentile calculation. The lifetimes library is useful where you want probabilistic CLV alongside the basic RFM (a separate FAQ covers CLV). For the segment assignment logic, custom code is usually clearer than a library because the segment definitions are business-specific. The standard data science stack covers RFM end to end without exotic dependencies.

The lifetimes library (https://github.com/CamDavidsonPilon/lifetimes) is the standard for non-contractual probabilistic CLV. It implements BG/NBD, Pareto/NBD, BG-BB, and Gamma-Gamma with clean APIs. For custom models or specific business shapes, the standard data science stack (pandas, NumPy, scikit-learn, PyMC for Bayesian models) covers the gaps. For subscription businesses, custom code or specific churn-modelling libraries (lifelines for survival analysis) are often more useful than the lifetimes library. The choice depends on the business model.

Model choice falls into three rough categories. GPT-4 family models for high-quality reasoning, complex tasks, and applications where output quality matters more than cost. GPT-3.5 family for high-volume, cost-sensitive applications where the simpler model is sufficient. Embedding models (text-embedding-3-large, text-embedding-3-small) for vector generation in RAG systems. The right choice depends on the use case: most production applications use a mix, with the more capable model for hard tasks and the cheaper model for routine ones.

Most AI projects fail on trust, not intelligence. Gartner reports that eighty-five per cent of AI projects fail to deliver business value. The technology usually works. The decisions do not follow because stakeholders cannot verify what the AI told them, cannot trace the evidence, and rationally refuse to act on confident-sounding outputs that arrive with no provenance. The fix is a trust framework that travels with every AI output, not better models.

AI governance matters more for analytics than for a typical AI chatbot because analytics outputs are used to make real business decisions - budget allocations, stock orders, pricing changes - often by people who are not equipped to independently verify a number's origin. A generic AI chatbot giving a slightly wrong general-knowledge answer is a minor annoyance; an AI-generated business metric that is subtly wrong and gets acted on can be genuinely costly.

Hopton uses its own frameworks rather than relying purely on Microsoft's or Pyramid's built-in trust features because platform-level features (semantic model certification, RLS, audit logs) are necessary but not sufficient on their own. Our frameworks exist to make sure those platform capabilities are actually configured properly and communicated clearly to business users, rather than assuming the presence of a feature equals responsible use of it.

Benchmarking matters because the most expensive analytics decision is the one made without understanding the starting position. Most analytics projects fail because of governance, skills, or adoption problems rather than technology. Buying a new platform amplifies whatever you already have, so weak foundations get amplified into bigger problems faster. Knowing where you stand prevents the most common failure pattern: jumping to a platform decision before the foundations are ready.

Customer lifetime value (CLV) is important because it makes the future-value implications of customer behaviour visible in the present. Without CLV, businesses optimise for short-term metrics (this period's revenue, this campaign's ROI) and miss the long-term consequences. With CLV, acquisition spend can be calibrated against the value of the customers being acquired, retention investment can be focused on the customers who are worth keeping, and segmentation can prioritise the groups that drive most of the long-term value. CLV is the analytical foundation of customer-led commercial strategy.

RAG is so important for business applications because foundation models do not know your business. They were trained on public data (with a cutoff date) and have no knowledge of your contracts, your product catalogue, your internal procedures, or your customer history. RAG bridges the gap: the foundation model provides the language and reasoning capability; RAG provides the specific knowledge. For most mid-market business GenAI use cases, RAG is the right default architecture. Without it, the model can only answer general questions; with it, the model can answer questions about your specific business.

RFM is still relevant in 2026 because it works, the data requirements are minimal, and the output is interpretable by non-technical stakeholders. More sophisticated segmentation techniques (clustering, propensity modelling, deep learning approaches) often produce segments that are statistically defensible but commercially opaque. RFM produces segments that the marketing team can immediately recognise and act on. The technique pays back fastest when paired with marketing automation and customer-level engagement; it remains undervalued in mid-market relative to its impact.

You can trust our AI advice, even though we sell AI services, because the projects that fail cost us more than the work we do not win. A failed AI engagement damages our reputation and our renewal pipeline far more than a clean 'defer this' recommendation costs us in this one project. We have a documented track record of recommending deferral when foundations were not ready, and of recommending non-AI fixes when those would deliver more value. Ask for examples and we will share them.

Yes — Hopton will give us an honest view on our score. Share your score with us and we will give you a frank read on what to prioritise, free of charge. If your foundations are not ready for the platform investment you are considering, we will say so, even though that means delaying work we could otherwise be doing. The point is for the assessment to actually help you, not to drive a sales process.

Under the standard Microsoft commercial agreement, your tenant data is protected from being used to train Microsoft's underlying models. M365 Copilot, Power BI Copilot, and Fabric Copilot all operate within the tenant's data boundary. That does not remove the privacy and governance question entirely. Internal access controls still apply, data classification still matters, and Copilot tends to make existing access policies more visible. Most clients discover that their access controls were less tight than they thought.

No — Power BI and Fabric cannot fix data quality problems on their own. Both platforms can surface data quality issues clearly and can apply cleansing logic during transformation, but neither can decide what your definition of an active customer should be, or reconcile two genuinely conflicting golden records. That is a business decision, not a technical one, and it has to be made by people who own the data, not by the reporting layer sitting on top of it.

Purview includes data quality scoring and profiling capability that can flag issues such as missing values, out-of-range figures, and format inconsistencies against rules you define. It surfaces and scores issues; resolving them - deciding which record wins, fixing the source system, or building a reconciliation rule - is still a deliberate design and governance decision.

Yes — you can get the one-page framework as a template. We share our working version with clients on request. No commitment required. The framework belongs to whoever is using it: tailor it to your environment, change the naming patterns to suit your conventions, extend it where the basics do not cover your situation. The point is for it to fit your team, not to be copied verbatim.

Most mid-market businesses have an MDM problem well before they have MDM tooling. Duplicate customer records across a CRM and an ERP, inconsistent product hierarchies between a webshop and a warehouse system, and conflicting cost centre structures between finance and operations are common at businesses far smaller than the enterprises MDM software is traditionally marketed to. The problem exists regardless of whether you have named tooling for it.

Purview has value even in a Power BI-only estate, particularly for lineage (tracing where a number in a report actually originated) and for applying consistent sensitivity labels across reports. Its value increases significantly once Fabric is in play, because Purview then has visibility across the wider lakehouse, warehouse, and pipeline estate, not just the semantic model layer.

Master data management is folded into wider Power BI, Fabric, and data governance engagements rather than sold as a separate, generic MDM project. In our experience, master data problems are best fixed in the context of the specific reports and decisions they affect, rather than as an abstract cleanup exercise disconnected from a concrete business use.

Hopton handles both Irish data protection requirements and UK GDPR, as first-class requirements rather than an afterthought. Irish clients sit under the EU GDPR framework enforced by the Data Protection Commission rather than the UK's ICO, and where an engagement spans both jurisdictions - a UK head office with an Irish subsidiary, or vice versa - we build the governance model, including row-level security, data classification, and retention rules, so it holds up against either regulator rather than defaulting to whichever one we know best. This is the same governance discipline we already apply to clients running multi-currency consolidation and cross-border reporting between UK and Irish entities.

Hopton uses Microsoft Purview where it adds genuine value, particularly for lineage and sensitivity labelling on Fabric-based estates. We do not deploy Purview by default on every engagement; smaller Power BI-only estates sometimes get equivalent value from simpler governance documentation without the additional platform overhead.

No — data governance does not need a Chief Data Officer, particularly not in mid-market organisations. Governance does not need senior structure to begin. It needs a small set of rules, a few people who agree to follow them, and the discipline to keep doing so. Waiting for a CDO is one of the most common reasons governance does not start. The environment continues to sprawl while the role is being scoped, and the longer the wait, the harder the eventual cleanup.

Fixing data quality means both cleaning up source systems and handling issues in the reporting layer, and the right mix depends on severity. Minor formatting inconsistencies can reasonably be normalised during data transformation in Fabric or Power Query. Genuine duplicate or conflicting master records need to be fixed at the source, or reconciliation logic needs to be built and maintained deliberately, because patching the same problem invisibly in every downstream report is fragile and eventually breaks.

Yes — the Checklist applies particularly to AI outputs. AI outputs land on a desk with confidence and no provenance, and the Checklist forces the same trust signals human-produced analysis used to carry. The four questions (Sources, Freshness, Limits, Action) are the same four blocks that appear in the Model Trust One-Pager from our AI guide. Both come from Nick Kelly's work on trust storytelling.

No — the Project Gate does not apply to AI projects only. We use it for every project, not just AI. The risk of admiration projects is universal. The Project Gate is particularly important for AI projects because they tend to attract enthusiasm and budget faster than they accumulate operational readiness, but the framework applies anywhere project work is being committed to.

Duplicate records happen in the first place usually through independent data entry across systems that were never designed to be the master for the same entity - a sales rep creating a new CRM contact instead of searching for the existing one, a new supplier being set up in the ERP without checking whether they already exist under a slightly different name. Left unmanaged, this compounds over years.

To find out how bad your own data quality problem is, ask us for a discovery conversation. Most clients underestimate the scale of the issue until we walk through a specific reconciliation exercise on their actual customer or product data, which is usually more revealing - and quicker to do - than it sounds.

Email hello@hoptonanalytics.com describing your current systems and where you suspect (or have already found) inconsistencies. We will scope an initial discovery conversation and, where useful, a specific reconciliation exercise on your most business-critical entity before recommending a wider programme of work.

To make governance routine rather than ceremonial, embed it — do not announce it. Avoid the all-hands meeting, the kick-off, the policy email. None of those change behaviour. Instead, embed the rules into work the team is already doing. The next workspace someone creates uses the naming convention. The next dataset deployed has a named owner. The next report promoted goes through the checklist. After a few weeks, the rules are how things get done. After a few months, the team would not know how to work any other way.

We decide which entities need formal master data management first by starting with whichever entity appears most often across the reports that matter most, and where a mismatch would be most damaging if it went unnoticed. For most mid-market businesses, that is customer and product; for some it is cost centre or location. We prioritise based on where a data quality issue would actually change a decision, not by trying to fix everything at once.

We handle data security and compliance by building everything within your own Azure tenant - your data never leaves your environment. We adhere to ISO 27001-aligned practices and can work within your existing governance and compliance frameworks. Row-level security, workspace management, and endorsed datasets are standard deliverables in every Power BI engagement, not optional extras.

Access control answers who can see or change what; KPI governance answers whether the number itself can be trusted, and both need the same discipline. Each KPI is documented once: its formula, the table and column it draws from, a named owner accountable for it, and where it is meant to be used, so two departments cannot end up with two different definitions of active customer or gross margin without anyone noticing. Changing a KPI's definition goes through the same promotion process as any other change to a certified model, not a quiet edit inside one report. Ownership sits with a named person rather than a team, for the same reason access control uses row-level security rather than ad-hoc filters: a rule with nobody accountable for it degrades over time. In practice this pairs directly with access control. Workspace roles and row-level security decide who can open a report and what rows they see inside it; the KPI's documented definition and owner decide whether what they are looking at means what they think it means. Get one right without the other and the result is either a secure report showing the wrong number, or a correct number that anyone can quietly redefine.

Hopton uses the BVQ at four points in our process. In discovery: we open with the BVQ and ask the client to complete it with us. In proposals: every proposed workstream has a BVQ attached. In sprints: we review the BVQ at the start of every sprint to check whether the decision, the owner, or the deadline have shifted. In delivery: we present findings against the BVQ. Not what we built, but the decision it supports, the evidence behind it, and what the client should do next.

Hopton handles a client whose master data is a mess directly, without pretending the reporting layer alone can fix it. We identify the highest-impact reconciliation work, agree who owns the decision on each entity, and sequence the analytics build around getting the most business-critical entities right first, rather than promising a dashboard can paper over unresolved data quality problems.

For a mid-market business, data governance should be lightweight, business-led and incremental — not the enterprise committee model. Pick the metrics that cause the most disputes, give each a business owner, agree and certify the definition behind it, add quality controls, then expand. Executive sponsorship keeps it honest, but the day-to-day stays with the people who use the data. You are building a habit, not a bureaucracy.

Data lineage in Purview helps with data quality by making it possible to trace a suspicious number backwards through every transformation step to its source, rather than debugging blind. This turns "the numbers don't match" from a multi-day investigation into a lineage trace that usually takes minutes, which matters enormously when a finance director is asking why a report has changed.

Governance fits into the Analytics Acceleration Programme naturally, as an ongoing discipline rather than a one-off. Governance is not a one-off project. The framework needs maintenance, the quarterly reviews need running, the rules need extending as the environment grows. The AAP gives you a dedicated allocation of consulting days each month over twelve or twenty-four months, which is the right shape for ongoing governance work. Most AAP engagements have governance as a standing component rather than a separate workstream.

Poor data quality shows up to a business user as a dashboard number that "doesn't look right" and gets quietly ignored, or worse, a decision made on a number that looks right but is not. The most damaging data quality problems are the ones that are subtle enough to go unchallenged rather than obviously broken.

Transactional data is the record of events: an order, an invoice, a stock movement. Master data is the relatively stable reference information those events point back to: which customer placed the order, which product was invoiced, which warehouse the stock moved through. Transactional data changes constantly; master data should change rarely and deliberately.

The BVQ is broader and applies to every piece of work, including small ones. The Project Gate is a sharper version applied to projects specifically, with an emphasis on operational readiness. A project with a good BVQ might still fail the Project Gate if the data owner cannot unblock access in time, or if the decision window closes before the project finishes. Both checks are useful. The Project Gate is what we use when the question is 'is this project ready to start' rather than 'is this work worth doing'.

The Trust Storytelling Checklist differs from the BVQ in its position in the workflow. The BVQ sits at the start of work, before anything begins, ensuring the work is worth doing. The Trust Storytelling Checklist sits at the end of work, before anything is delivered, ensuring the work is safe to act on. Both are essential. Both are short. Both make the difference between consultancy that produces deliverables and consultancy that produces decisions.

Governance documentation only needs to be one page to start. The framework we use covers the Business Value Question, the four practices, and the quarterly review on a single page. The argument for the page is longer, naturally. But the page itself, the thing your team lives by, has to be short. Nobody refers to a fifty-page policy document at 9am on a Tuesday. They refer to a one-page reference pinned to the team's shared workspace.

Once set up, MDM and data quality require meaningful but bounded ongoing effort: new records still get created imperfectly, and someone needs to own periodic review and reconciliation. This is one of the reasons we build data governance and data quality maintenance into ongoing support arrangements rather than treating it as a one-off project that is "done" at go-live.

Access controls come down to two questions: who can see what data, and who can change what content. For data access, row-level security in the semantic model is the right pattern. For content access, workspace permissions follow a small number of standard roles (viewer, contributor, member, admin). Avoid bespoke role structures: they become unmanageable quickly. Standard roles are easier to maintain, easier to audit, and easier to understand for everyone in the team.

No — Purview is not the same thing as master data management. Purview is primarily a cataloguing, lineage, and governance tool; it helps you see and control your data estate. MDM is the broader discipline of actively defining and maintaining golden records for your core entities. Purview can support an MDM programme by surfacing where inconsistencies exist, but it does not itself decide or enforce which record is the true one.

Data quality assessment is part of the Establish phase discovery work in our AAP. The scope and depth of remediation work needed varies significantly by client, and where it is substantial, we scope it explicitly rather than absorbing an open-ended cleanup exercise inside a fixed-price Build phase.

No — governance should not be a separate workstream from delivery. Governance must be embedded in delivery, applied to the dataset being deployed this week, the report being promoted, the model being shared. Anything else is theatre. A governance team that writes rules separately from the delivery team that builds reports rarely produces governance that anyone follows. The rules have to live where the work happens.

The four data-governance practices that follow the Business Value Question are naming conventions, named ownership, a promotion process, and access controls. Together with the BVQ and a quarterly review, they form a six-section framework that fits on one page. Each practice is simple. Together they prevent most of the problems that ungoverned environments create. The four practices are intentionally minimal. They cover the basics every environment needs without the heavy structure most governance attempts get caught up in.

The most common data quality issues in mid-market analytics estates are duplicate customer or supplier records created by inconsistent entry across systems, inconsistent product or account hierarchies between operational systems, missing or stale reference data (old cost centres, discontinued products still appearing in reports), and definitional drift, where the same metric name means different things in different systems because no one agreed a single definition.

A single source of truth means every team is looking at the same numbers, built from the same definitions. In practice it comes from three things working together: a certified semantic model where measures like "revenue" or "active customer" are defined once and reused everywhere, documented ownership so everyone knows which report is authoritative, and governance that stops parallel, unofficial versions taking root. It is an outcome of governed architecture, not a tool you switch on. Clients who reach this point consistently describe the same shift: leadership stops debating whose numbers are right and starts spending that time on the decision itself.

Purview is Microsoft's data governance and cataloguing service. It scans data estates (across Azure, Fabric, and beyond) to build a searchable catalogue of what data exists and where, tracks data lineage so you can see where a number in a report actually came from, applies sensitivity labels and access policies consistently, and gives a central place to see data quality metrics across your estate.

A good naming convention is short enough that everyone remembers it. We typically use a domain-purpose-environment pattern: domain (Finance, Sales, Operations), purpose (Pipeline, Cash Flow, Stock Performance), and environment (Dev, Test, Prod). 'Finance - Sales - Production' is meaningful. 'Final Report v3' is not. The convention should cover workspaces, datasets, reports, and measures consistently. Longer or more complex conventions get followed inconsistently and quickly become noise.

A good promotion process uses three environments: development, test, and production. New work is built in Dev. It is validated in Test by people other than the builder. It is promoted to Prod only after that validation passes. For a small team, the promotion process can be a checklist: model documented, security tested, refresh schedule confirmed, two stakeholders signed off. The point is to prevent accidents, not to slow delivery.

A practical first step towards MDM, for a business with no formal programme today, is a reconciliation exercise: identify your core entities, compare how each is represented across your two or three most important systems, and agree which system (or which combination) is authoritative for each field. This does not require buying dedicated MDM software; it requires a decision-making exercise that most mid-market businesses have simply never done formally.

For a mid-market organisation, data governance means: agreed definitions for every key metric (what does 'revenue' include?), clear ownership of datasets and reports (who is responsible for accuracy?), documented data lineage (where does each number come from?), access controls (who can see what?), and a process for managing changes. Governance is not a one-time project - it is the operational discipline that keeps analytics trustworthy over time.

The first 90 days of a governance rollout run week by week: in weeks 1-2, agree the one-page framework, identify owners for every existing dataset and shared report, and sort the most obvious naming inconsistencies. Weeks 3-6: apply the framework to all new content, set up the promotion process, establish workspace roles, document the rules. Weeks 7-10: bring existing content into compliance, rename what needs renaming, reassign orphans, retire content no longer used. Weeks 11-12: run the first quarterly review, confirm what is working and what is not, adjust where the rules turned out to be wrong or missing.

The quarterly data-governance review checks four things. Ownership refresh: are the named owners still the right people, has anyone left or changed role. Naming compliance: has new content followed the convention, are there outliers to clean up. Sprawl audit: what new workspaces, datasets and reports have appeared, are they all needed. Framework fitness: are the rules still matching the environment, anything missing or unnecessary. Thirty minutes is usually enough. The point is to keep the framework alive, not to redesign it every quarter.

Each block of the Business Value Question (BVQ) captures one thing, starting with the decision: what specific decision will this work inform, in plain language. The decision owner: a named person, not a team or committee, with authority to act. The action: what will the decision owner do differently, specific and observable. The measurement: how will we know if the decision was successful, with concrete metrics. The deadline: when does this decision need to be made. The cost of inaction: what happens if this decision is not made or is made without data.

If you cannot name a decision owner for a piece of analytics work, then the work is not ready to start. A specific named person, not a team, not a committee. They must have the authority to approve, defer, or reject the recommendation. If you cannot name them, the project is still conceptual. This is one of the most valuable findings from running the BVQ: it surfaces work that everybody assumes will be useful but nobody can defend at the level of who will actually act on it.

A "golden record" is the single, agreed, trusted version of a master data entity - the one definition of a given customer, product, or supplier that all systems should ultimately treat as authoritative, even if the raw data about that entity still lives in several source systems.

A certified dataset is one with an explicit owner, documented lineage, quality checks, monitoring, and a recertification cadence, so anyone building on it knows it is trustworthy and current. Certification turns governance from a policy document into something operational, and its lineage lets you answer why did this number change with a fact rather than a guess.

A single source of truth in analytics is one agreed definition for each key metric, more than it is a single physical database. When departments calculate active customer or net revenue differently, no report can be trusted. A single source of truth centralises the business logic — standardised definitions held in a governed semantic model — so every report inherits the same calculation and the numbers finally agree.

Data lineage is the documented record of where each piece of data comes from, how it has been transformed, and where it is used. It matters because when a number looks wrong, lineage tells you exactly where to look. Without it, debugging a data quality issue means tracing the problem manually through every system and transformation. Fabric and Power BI both have built-in lineage views that we configure and maintain as part of every engagement.

Incremental data quality is the practice of treating quality rules as something that grows over time rather than a one-off cleansing project. A new rule gets added whenever a new failure mode is discovered, and because the raw layer is immutable and the pipeline replayable, that rule can be run back across the full history immediately rather than only applying from the day it was written.

Master data management (MDM) is the discipline of agreeing, in one place, what the core reference entities in your business actually are - your customer list, your product list, your chart of accounts, your cost centres - so that every system and every report refers to the same version of the truth rather than each holding its own slightly different copy.

The Business Value Question is the single discipline that anchors every piece of work we do. Six blocks: the decision, the decision owner, the action, the measurement, the deadline, and the cost of inaction. We complete the BVQ with the client at the start of every engagement, every proposal, every sprint. If we cannot complete it, the work stays in the framing stage. It does not start until it can. The BVQ prevents technically impressive work that changes nothing in practice.

The Hopton Governance Workshop is a one-day structured workshop with your team and ours. Morning: assess your current environment together. What exists, who owns it, where the gaps are, what has been tried before. Afternoon: work through the BVQ and the four practices for your environment. Output: a working one-page framework, a named-owner spreadsheet for your existing estate, and a 90-day plan. Fixed-scope, no obligation to continue afterwards. Many clients do, but the framework belongs to them either way.

The Project Gate is a four-point check that prevents what we call 'admiration projects': work that looks impressive in demos but changes nothing in practice. All four must be answered before work is committed to. Decision owner: a specific named person with authority and a decision window open during the project. Concrete action: the decision owner can describe what they will do differently. Measurement window: impact can be measured within the project timeline. Data owner: a named person who can unblock data access. If a request cannot pass this gate, it is not ready to consume the team's capacity.

The Trust Storytelling Delivery Checklist is four questions every deliverable must pass before it goes to a stakeholder: Sources (can we show exactly which data sources this analysis is based on), Freshness (can we tell the client how current this data is), Limits (have we stated where this analysis is weak or based on assumptions), and Action (does the deliverable say what the client should do next). If any answer is no, the deliverable goes back to the team. The Checklist ensures the work is safe to act on, where the BVQ ensures the work is worth doing.

You should extend the data-governance framework beyond the basics when the cost of not extending becomes obvious. Sensitive data classification becomes worth adding once you have more than a couple of domains. Lineage tracking helps when datasets feed each other in non-trivial chains. A lightweight data dictionary helps when more than a handful of people are building reports. Premature governance is as bad as no governance: both produce overhead without value. The discipline is to add things only when the absence becomes visible as a real problem.

The full data governance guide is on hoptonanalytics.com under Resources. The guide covers why governance fails, the BVQ in detail, the four practices, the Trust Storytelling Delivery Checklist, the Project Gate, the 90-day rollout, the quarterly review, and how to extend the framework as the environment grows. To discuss your specific situation or request the one-page template, email hello@hoptonanalytics.com.

MDM work fits in an analytics project before building dashboards, ideally, at least for the entities that matter most (customer, product, and whichever master entity your specific business runs on). Building dashboards on top of unreconciled master data means rebuilding the semantic model later once the inconsistencies surface, which almost always costs more than addressing them up front.

Hidden complexity in analytics projects usually comes from four places, most commonly: ETL logic that has to handle far more source exceptions than anyone estimated, governance requirements that surface once real users and real permissions are involved, validation rules that reveal disagreements between departments about what a number means, and cross-department alignment that turns out to need more meetings than the plan allowed for. None of these are unusual. They are just rarely priced in up front.

Most data governance initiatives fail in five recurring patterns. First, the 50-page policy document that becomes evidence governance exists rather than something that shapes behaviour. Second, waiting for a Chief Data Officer or formal committee before starting. Third, treating governance as a separate workstream from delivery. Fourth, confusing governance with control, which kills delivery and gets routed around. Fifth, no review cadence, so the framework drifts out of date and becomes irrelevant.

Organisations struggle with data governance because governance tends to be treated as a compliance exercise rather than a delivery discipline. Most analytics projects focus on building reports and move on - the governance layer gets skipped because it adds time and does not produce a visible output. The result is an analytics estate that works at the start and degrades as the business changes. We embed governance into every engagement from day one because retrofitting it later is significantly harder.

Master data quality matters so much for Power BI and Fabric because a semantic model is only as trustworthy as the master data underneath it. If "customer" means something slightly different in your CRM than it does in your finance system, a Power BI report joining the two will silently produce numbers that do not reconcile, and no amount of good dashboard design fixes a broken join underneath it.

Every dataset, every workspace, every shared report needs a named owner: a specific person, not a team or 'IT' or 'the data team'. The owner is responsible for refresh schedules, documentation, security, and decisions about change. Without named ownership, content becomes orphaned, refresh schedules drift, and nobody can authorise change. When that person leaves the organisation or moves to another role, the ownership transfers explicitly.

The Business Value Question (BVQ) is so central to governance because before any naming convention or ownership rule, governance starts with a question: what decision is this work supposed to inform? If you cannot answer that, the work is not ready, regardless of how well it is named, owned, or promoted. Naming and ownership protect work that is worth doing. The BVQ decides whether the work is worth doing in the first place. Without it, you can run a perfectly governed environment full of technically excellent reports that change nothing.

The Trust Storytelling Checklist is so important at the moment of delivery because the moment of delivery is when trust is built or broken. Not policy documents. Not steering groups. The handover of a dashboard, a report, or an analytical finding to a stakeholder. A confident, well-sourced delivery makes the decision feel safe to take. A vague, hedged delivery does the opposite, regardless of how good the underlying analysis is. Stakeholders do not resist data because they do not understand it. They resist it because acting on it carries personal risk. The Checklist reduces that risk.

You should not report directly off raw source data because raw operational data is not written for reporting, it is written for the system that captures it. It contains duplicates from retries, records mid-transaction, inconsistent keys across source systems, and no agreed business logic for things like an active customer or a completed order. Reporting directly against it means every analyst rebuilds those rules themselves, differently, which is exactly how two dashboards end up disagreeing. Validating and modelling the data once, in Silver and Gold, means everyone downstream works from the same trusted answer.

The raw data layer should be immutable because it is your only honest record of what the source system actually sent you, and your only way back if something downstream goes wrong. If a transformation bug corrupts the Silver layer, or a new business rule needs applying to two years of history, an immutable Bronze layer means you can simply reprocess from the original data. If Bronze has already been cleaned, reshaped or overwritten, that option is gone, and you are stuck trying to reconstruct history from a Gold table that was never meant to hold it.

Yes — Hopton will tell you if your existing governance is fine and you don't need help, and we sometimes do. If your governance is working, we will say so and recommend you stick with it. The audit of your current state is part of the workshop and we report honestly on what we find. The point of the engagement is to help you make governance work, not to sell our help if you do not need it.

Use Fabric Data Factory for new builds in most cases, rather than Azure Data Factory (ADF). The capabilities are similar (and growing closer) but the Fabric version integrates natively with OneLake and the rest of the Fabric platform without separate connection management. For existing ADF investments, the migration path to Fabric Data Factory is straightforward but not always urgent; existing ADF pipelines continue to work and can stay on standalone ADF for the foreseeable future. For new mid-market analytics builds, the default is Fabric Data Factory.

Yes — Microsoft Fabric and Databricks are increasingly competing for the same workloads. Both platforms can do most things: lakehouse, data warehouse, BI, ML, real-time. The competition is real. The differences are in optimisation and culture rather than capability. Fabric is built around BI-led mixed workloads. Databricks is built around code-first lakehouse and ML. Both can do the other thing, but each is designed for a different centre of gravity, and that is what shapes the decision.

Yes, for the workloads most mid-market businesses actually run. Both are credible cloud data platforms, both use a lakehouse-style architecture, and both bill on consumption rather than fixed licence tiers. The differences are in ecosystem fit and specialisation rather than raw capability. Fabric's advantage is native integration with Power BI, Azure, and M365, plus OneLake as a single storage layer. Snowflake's advantage is genuine multi-cloud portability across AWS, Azure, and GCP, and a data-sharing model some organisations rely on for external data collaboration. Neither has a decisive edge in AI engineering specialisation over the other today. The decision is rarely about which is technically better. It is usually about which fits your team, your existing estate, and whether multi-cloud is a real requirement or a hypothetical one.

Yes — both platforms have non-obvious costs worth knowing. Fabric capacity sizing is its own learning curve, and over-provisioning is common in early Fabric deployments. Databricks workspaces can sprawl, with notebook clusters left running and unmanaged. Both vendors have monitoring tools. Use them from day one rather than discovering the bill at month-end.

If you scored nine or above, you are likely ready to consider Fabric. The Building stage is where structured platform investment usually starts paying back. Below nine, fix the foundations first. A new platform amplifies the problems, not solves them. The Fabric Adoption Playbook covers the platform decision in detail; the assessment tells you whether to start that conversation now or later.

Azure Data Factory (and Synapse) suits teams with an established Azure estate and heavy, cost-sensitive orchestration that want granular control. Microsoft Fabric suits teams who want ingestion, storage, transformation and Power BI unified in one governed SaaS platform and value simplicity. For most mid-market organisations, Fabric’s consolidation is the better fit; the mistake to avoid is buying a large multi-cloud platform you do not need.

Use Azure SQL Database for most use cases, and Azure SQL Managed Instance for specific compatibility requirements. Azure SQL Database is the modern, fully-managed PaaS database with the lowest operational overhead. Managed Instance offers near-100 per cent compatibility with on-premises SQL Server, which matters for migrations from existing SQL Server environments where breaking changes would be costly. For new mid-market data platforms, Azure SQL Database is usually the default. For lift-and-shift migrations of existing SQL Server estates, Managed Instance may be the easier path.

CDC (change data capture) and event streaming are different patterns serving different purposes. CDC captures changes from a transactional database and streams them to the analytical platform; the source is a database. Event streaming captures discrete events from applications, devices, or APIs; the source is an event producer. CDC is appropriate for analytical platforms that need to track changes in transactional data. Event streaming is appropriate for systems that produce events natively. Many real-time implementations use both, with CDC bringing in operational system changes alongside event streams from applications and devices.

Yes — Fabric can coexist with existing Power BI and Azure investments. Fabric does not require ripping out existing Power BI investments; it extends them. Existing Power BI Pro licences continue to work, existing reports continue to run, and the migration path from Power BI Premium to Fabric capacity is well-documented. Existing Azure data investments (ADF, Synapse, Azure SQL, Storage) can be progressively migrated to Fabric or kept where they are with Fabric reading from them. The transition is incremental rather than a forklift replacement, which suits mid-market budgets and risk appetite.

Yes — Fabric can do ML. Fabric's Data Science workload covers the end-to-end ML workflow in one environment: Spark-based notebooks for data ingestion and experimentation, AutoML for automated model selection and tuning, built-in MLflow for experiment tracking and model registry, and direct deployment of model output into Power BI reports. Real-time intelligence and Copilot-based conversational analytics agents sit alongside this, so a business user can query a model's output in natural language rather than writing code. The tools are credible. The ecosystem maturity is younger than Databricks. For most mid-market ML use cases (forecasting, classification, basic recommendations), Fabric is enough. For deep ML workflows with serious MLOps requirements, Databricks remains stronger.

Fabric usually cannot replace your planning system. Planning systems handle the workflow (scenario building, approval cycles, exception management, S&OP processes) that Fabric does not. Fabric handles the analytical layer (statistical forecasting, accuracy tracking, multi-source data integration) that the planning systems often handle weakly. The two work together. For very small operations a Fabric-only approach might work; for serious supply chain operations the planning system stays in place and Fabric augments it.

Yes — Hopton can build the architecture without delivering the reports. Some clients engage us for the data engineering and architecture workstream specifically, with the reporting and visualisation handled by their internal team or another partner. The architectural deliverables (lakehouse structure, ingestion pipelines, semantic model design, deployment pipelines) are independent of the report build. The engagement scope is flexible. We are equally willing to deliver the full stack or a specific layer.

Yes — Hopton can design your Azure data architecture. Architecture design is part of every Establish phase. The output is a written architecture document covering the Azure services to be used, how they fit together, the cost model, the security posture, the operational model, and the migration path from existing systems. The architecture is the foundation of the build phase that follows, but the architecture document is also useful as a standalone deliverable. Some clients use us for architecture only and deliver the build with internal teams or other partners.

Yes — Hopton can help you decide whether Fabric is right for your business. The Reporting Modernisation Assessment (a four-week fixed-price engagement) is the structured way to get an independent view. Output is a written assessment with a clear recommendation: Fabric, alternatives, or a phased approach. We have written assessments recommending against Fabric where the business case did not support it, and we have written several recommending it. The framework decides, not the commercial bias toward selling more work.

Yes — Hopton can review your existing data architecture. The Power BI Health Check (a two-week fixed-price engagement) covers the data architecture alongside the Power BI estate. For deeper architectural reviews on existing Fabric or Azure data platforms, we run extended assessments (typically four to six weeks) covering medallion structure, ingestion patterns, SCD handling, deployment maturity, and observability. Output is a written report with prioritised recommendations and a roadmap. The assessment is independent of any subsequent build engagement.

Yes — market basket analysis can inform promotional design, in two patterns. First, promote anchor products (those with strong outgoing associations) to drive baskets, accepting the margin sacrifice on the anchor for the basket-building uplift on associated products. Second, avoid promoting strongly co-purchased products simultaneously: if customers already buy A and B together, promoting both is unnecessary spending. The MBA-informed promotional plan is usually meaningfully different from the intuition-based plan, and the difference is measurable in basket-level uplift. We have run promotional optimisation work for retailers using MBA as the foundation.

Yes — anomaly detection can support customer behaviour monitoring. Pattern detection on customer behaviour can surface accounts at risk of churn (sudden behaviour change), accounts at risk of fraud or compromise (unusual access patterns), and accounts that may be growing through organisational change (revenue patterns shifting). The challenge is distinguishing meaningful customer-level anomalies from natural variation, which requires careful baseline construction. Per-customer baselines work better than population baselines for established customer relationships.

Real-time can sometimes replace daily reporting, for the right use cases. The high-frequency operational dashboards benefit from real-time. The strategic management reporting (monthly P&L, quarterly board pack) does not. The right pattern is a layered approach: real-time dashboards for operational decisions, refreshed-hourly dashboards for tactical management, and traditional batch reporting for strategic and statutory needs. Trying to put everything on real-time produces an expensive and unnecessary platform; trying to use only batch produces lost operational opportunities. Both have a place.

Whether the forecast can run autonomously or needs human oversight depends on the use case. For high-volume, low-stakes decisions (routine replenishment of stable products), autonomous operation with monitoring is appropriate. For high-stakes decisions (new product launches, promotional commitments, capacity decisions), human oversight is essential. The pattern that works is the forecast as input to a human-in-the-loop process for important decisions, and as direct driver for routine decisions, with monitoring agents flagging anomalies for review. The design of the operational workflow matters as much as the forecasting itself.

Yes — you can move from Fabric to Snowflake later, or vice versa, with effort. Open table formats make data portability easier than it was. The harder parts are semantic models, BI tooling, security and the operational tooling around the platform. A migration is a real project, not a button-push, but it is no longer a one-way door. Choose well now and you will rarely need to migrate. Choose poorly and migration is a recoverable mistake.

Yes — you can reduce Fabric cost materially through reservations. Annual reservations save around 20 per cent off PAYG list prices. Three-year commitments through an Enterprise Agreement save up to 41 per cent. For workloads that only run during business hours, pausing capacity outside hours saves another 50 per cent on top. Combined, these can reduce Fabric capacity costs by 60 per cent or more against PAYG-without-pausing for typical mid-market patterns. The specific savings depend on your workload pattern; we cover sizing methodology in the True Cost FAQ.

Yes — you can run a quick MBA proof of concept. We extract a sample of transaction data, run MBA in Fabric Data Science, produce the rule output, and walk you through the results. The proof of concept produces real rules on your real transaction data, not a generic demonstration. Often the rules surfaced in the proof of concept directly inform commercial decisions, even before the full implementation. Two to three weeks is the typical duration.

Yes — you can run an anomaly detection proof of concept. A three to four week proof of concept on a representative data slice produces a working detector, validates the technique choice, and demonstrates the operational signal-to-noise ratio. The proof of concept output is often usable directly for some monitoring use cases, with the full implementation extending the coverage. Several of our anomaly detection engagements started as proofs of concept and grew into permanent monitoring capabilities.

Yes — you can use both platforms together, and some organisations do. Fabric for BI and analyst-led work, Databricks for engineering and ML. The integration is workable through OneLake shortcuts and shared open table formats. The cost is operational complexity. Most mid-market businesses find that one platform serves them better than two. Larger organisations with distinct teams sometimes choose both deliberately.

On open table formats, both Fabric and Databricks support Delta. Databricks supports Iceberg natively. Fabric currently leans on Delta. Open formats reduce vendor lock-in and make migration easier. They do not decide the platform choice on their own. The interoperability story is improving fast on both sides.

For most serious implementations, yes. The capability that Purview provides (sensitivity labels, classification, lineage tracking, access governance) is genuinely valuable and increasingly expected by stakeholders, auditors, and regulators. Smaller implementations can get by with less; once the data estate spans multiple sources and the user base is broader than a small team, governance discipline supported by tooling becomes important. The cost of Purview is reasonable; the cost of governance failure is much higher.

Both KQL and SQL work, with different strengths. KQL is the native language for eventhouses and Real-Time Intelligence; the queries run faster and the language better fits the time-series patterns. SQL is supported through cross-Fabric queries and is more familiar for most analysts. For exploratory work and ad-hoc queries, KQL fluency makes a meaningful difference in productivity. For dashboards and reports built on top, the language choice matters less because the queries are written once and consumed many times. Most teams use a mix.

No — we do not work on Azure outside of data and analytics. Our scope is the Microsoft data and analytics stack. Azure as a broader cloud platform (compute, networking, identity, security, application services) is outside our specialism. We work with Azure data services because they are part of the data and analytics stack, but we do not deliver general Azure infrastructure work, application modernisation, or cloud migration outside the data context. For broader Azure work, we coordinate with specialist Azure partners.

For now Databricks does have better ML and AI tooling, on the ML side. MLflow, Feature Store, Unity Catalog and the wider MLOps ecosystem are more mature in Databricks than in Fabric. Fabric is closing the gap on the data science workload, but mature MLOps is a multi-year build and Databricks has been at it longer. For organisations with serious ML ambitions, this is a meaningful advantage.

Yes — Hopton does implement real-time analytics. Real-time and streaming analytics is part of our delivery scope when client use cases justify it. We have built real-time operational dashboards, supply chain visibility, and event-driven monitoring on Fabric Real-Time Intelligence. The team holds the relevant Microsoft certifications and has practical experience with the workload. Real-time is not the bulk of our work (most mid-market analytics is batch-led) but it is a capability we deliver when the use case is right.

Azure data services are at the centre of our work alongside Power BI, Microsoft Fabric, and Microsoft Dynamics 365 Business Central. Most of our engagements involve Azure Data Factory, Azure SQL, Azure Storage, and Microsoft Purview at minimum. Many include Azure Machine Learning, Azure OpenAI, or Azure-hosted infrastructure. The team holds individual Microsoft certifications across the Azure data stack. Azure is not a separate specialism for us; it is part of the Microsoft data and analytics stack we work in daily.

Yes — Hopton does specialise in data engineering and architecture. Data engineering and architecture is at the centre of our work. Most of our engagements include the architectural design and implementation work alongside the analytical and reporting layer. The team includes data architects and engineers with practical experience building Fabric and Azure data platforms across mid-market sectors. Several team members hold individual Microsoft certifications including the DP-700 (Fabric Data Engineer) and the broader Azure data certifications. Architecture is not a sideline for us.

Hopton works with the broader Microsoft stack, not Fabric only. Fabric is one of our core technologies alongside Power BI, Azure Data Factory, Azure SQL, Azure Machine Learning, Microsoft Purview, and Microsoft Dynamics 365 Business Central. The strength is in knowing how these components fit together. Many of our engagements span Fabric and other Azure or Microsoft 365 services. Specialising in Fabric without specialising in the surrounding Microsoft estate would limit the value we deliver.

Yes — market basket analysis works for non-retail businesses, with adjustments. The technique applies wherever transactions contain multiple items: financial products bought together, professional services purchased in combination, content consumed in sequence, courses taken in combination, pharmaceutical prescriptions in patient histories. The retail roots are visible in the terminology (basket, items) but the underlying maths is general. The data shape is the same: a transaction identifier and a set of items per transaction. Where the data fits the shape, MBA produces useful rules.

Not every organisation needs all three layers as separate physical layers on day one, but the three responsibilities of keeping raw data untouched, validating and conforming it, and modelling it for reporting exist in every platform whether they are named or not. Smaller estates sometimes combine Silver and Gold early on, but the moment reporting logic starts living in more than one place, splitting them out usually pays for itself.

Demand forecast accuracy is variable, by item and by horizon. For stable mature SKUs at weekly horizon, forecast errors of 10 to 20 per cent (mean absolute percentage error) are typical and good. For volatile or low-volume SKUs, errors of 30 to 50 per cent are common. For new products, forecast errors of 50 to 100 per cent or more are realistic. Aggregate accuracy is always better than SKU-level accuracy because errors cancel out. Setting realistic accuracy expectations is part of the early engagement; over-promising on accuracy produces disappointed stakeholders.

Azure ML, Azure OpenAI, and Copilot serve different layers of AI capability. Azure ML is for traditional machine learning (predictions, classifications, forecasting) on your own data. Azure OpenAI is for generative AI through direct API access for custom applications. Copilot products are the user-facing AI assistants embedded in Microsoft applications, built on top of OpenAI models with Microsoft's product-specific tuning. Most mid-market businesses end up using Copilot for the user-facing AI, Fabric Data Science for traditional ML, and Azure OpenAI selectively for custom generative AI applications. The choice depends on the specific use case.

Snowflake has had a longer head start on cross-organisation data sharing through Snowflake Marketplace and direct sharing. Fabric is catching up through OneLake shortcuts and external sharing. If multi-organisation data sharing is core to your business model, this currently favours Snowflake. For most mid-market businesses, it is a non-issue.

On open table formats, both Fabric and Snowflake support Delta Lake. Snowflake also supports Iceberg natively. Fabric uses Delta as the storage format underneath the Lakehouse component. Open formats reduce vendor lock-in and make some migration scenarios easier, but they do not decide the platform choice on their own. The decision is mostly about platform fit, not file format.

Email hello@hoptonanalytics.com with a brief description of your current Azure estate, what you are trying to achieve, and any existing investments. The first conversation is exploratory and free. If there is a fit, we propose a four-week Establish phase that produces an architecture, a priority list, and a written delivery plan. From there you can decide whether to proceed with the build.

Email hello@hoptonanalytics.com with a brief description of your current data and analytics estate, your main pain points, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a four-week Establish phase that produces an architecture, a priority list, and a written delivery plan. From there you can decide whether to proceed with the build.

Email hello@hoptonanalytics.com with a brief description of the use case (what kind of unusual behaviour are you trying to catch), the data sources, and the operational team that would respond to the alerts. The first conversation is exploratory and free. If there is a fit, we propose either a focused anomaly detection proof of concept or a broader analytics engagement that includes anomaly detection as one component.

Email hello@hoptonanalytics.com with a brief description of your current data estate (sources, current platform, scale), the architectural challenges you are facing, and what you are trying to achieve. The first conversation is exploratory and free. If there is a fit, we propose either a Health Check (lighter-touch review) or an architectural assessment (deeper review) as the structured next step.

Email hello@hoptonanalytics.com with a brief description of your supply chain operation, the products and SKUs you forecast, the planning systems already in place, and the specific accuracy or operational issues you are trying to solve. The first conversation is exploratory and free. If there is a fit, we propose either a four-week forecasting proof of concept or a broader supply chain analytics engagement that includes forecasting as one component.

Email hello@hoptonanalytics.com with a brief description of your transaction data, your basket sizes, and what commercial decisions you are looking to inform. The first conversation is exploratory and free. If there is a fit, we propose either a focused MBA implementation or a broader customer and product analytics engagement that includes MBA as one component.

To start a conversation about real-time analytics, email us at hello@hoptonanalytics.com with a brief description of the use case (what decision needs to be made faster, what events need to trigger action, what data sources are streaming-capable), and the current state of your data platform. The first conversation is exploratory and free. If there is a fit, we propose either a focused real-time scoping engagement or a broader analytics engagement that includes real-time alongside batch.

MBA rules inform store layout by revealing which products customers naturally buy together, so layouts can either encourage the association (placing the products near each other for convenience and uplift) or deliberately separate them (placing products at opposite ends of the store to extend the shopping journey). Both strategies have been used effectively. The decision depends on the business: convenience-led retailers tend to group; destination retailers tend to separate. The rules surface the choice; the merchandising team makes the call. Most mid-market retailers do not formally use MBA for layout decisions and many would benefit from doing so.

Basket size and product range affect market basket analysis through two practical considerations. Basket size: MBA needs baskets with multiple items to find associations. Single-item baskets contribute nothing. Retailers with average basket size of 1.0 to 1.5 items get less from MBA than retailers with baskets of 3+ items. Product range: very large ranges (tens of thousands of SKUs) produce sparse data where most pairs occur infrequently. Aggregating to category or sub-category level often produces more useful rules than analysis at SKU level. The right granularity is a business decision, usually middle-out.

Training and operability costs factor in heavily, and most pricing comparisons miss this. A platform your team can run with existing skills costs less in practice than one that requires hiring. Fabric tends to win on this for organisations with Power BI developers. Snowflake tends to win for organisations with strong SQL engineering teams. The platform you can run is almost always cheaper than the platform you have to staff up to run.

Training and team costs are heavily underweighted in most BI platform pricing comparisons. The platform your team can run with existing skills costs less in practice than one requiring hiring. Fabric tends to win for organisations with Power BI developers and analyst skillsets. Databricks tends to win for organisations with Python and Spark engineering capability. Hire the platform you have a team for, or have a plan to staff the one you need.

Avoiding alert fatigue in anomaly detection takes five disciplines. Calibrate thresholds against historical false positive rates so the alert volume is manageable. Tier alerts by severity so the most critical anomalies stand out from routine ones. Suppress duplicate alerts within a defined window. Route different alert types to the right teams rather than everything to one inbox. Track alert response and outcome so the calibration can improve over time. Without these disciplines, anomaly detection generates noise that gets ignored, defeating the point of the system. With them, the alerts that fire are the ones genuinely worth acting on.

To compare BI platform pricing fairly, build a representative workload and price both. Sample queries, refresh patterns, user counts. Most pricing comparisons are unfair because they price one platform at a typical workload and the other at peak. Both vendors have pricing calculators. Use them with realistic numbers, including non-production environments and growth assumptions.

Forecasting when products change frequently (range churn, NPI) is a common challenge in retail and consumer goods. New products without history cannot be forecast directly; the forecast has to come from comparable products (analogue forecasting), category-level patterns, or planning team input. The forecasting platform should handle the new-product case explicitly rather than treating it as a normal forecast. Mature products with stable histories are the easy part; the work is in handling the long tail of new and changing products well.

We handle data quality issues that look like anomalies carefully, because the line between 'data quality issue' and 'genuine anomaly' is sometimes thin. The pattern that works is two-stage: a data quality layer that filters out known data issues (missing values, duplicate records, schema violations) before the anomaly detection runs, and an anomaly detection layer that flags genuinely unusual events for review. Without the separation, anomaly detection produces a flood of false positives driven by data quality rather than business unusualness. The Trust Storytelling Delivery Checklist applies here particularly.

We handle promotional baskets in market basket analysis carefully. Promotions distort buying patterns: customers buy products together because they are on promotion, not because they have a natural affinity. Including promotional baskets without flagging them produces rules that reflect promotional planning rather than customer behaviour. The right approach is usually to tag promotional transactions, run MBA both with and without them, and compare the rules. The 'organic' rules (without promotions) are usually more useful for ranging and store layout; the 'with promotion' rules are useful for promotional design.

We handle promotional volatility in demand forecasting by treating promotions as features in the forecasting model. The historical promotional flags become predictors, and the forecast for future periods incorporates the planned promotional calendar. This produces promotion-aware forecasts that distinguish baseline demand from promotional uplift. The technique requires the historical promotional data to be captured cleanly, which is often the bottleneck. Without clean promotional history, the models attribute promotional uplift to other factors and produce poor forecasts in promotional periods.

We measure forecast quality through standard accuracy metrics: mean absolute error (MAE), mean absolute percentage error (MAPE), bias (whether the forecast systematically over- or under-shoots), and forecast value-add (whether the model is better than a naive baseline). The metrics are tracked over time and across SKU groups. Models that are getting worse trigger investigation. Models that are systematically biased need correction. The accuracy tracking is operational discipline, not just initial validation.

We test data pipelines in Microsoft Fabric through three test types. Unit tests on the transformation logic itself (does this Python function produce the expected output for known inputs). Integration tests on pipeline behaviour (does this pipeline correctly read from the source and write the expected schema to the destination). Data quality tests on the output (does the produced data meet the quality expectations: row counts in expected ranges, no null values in critical columns, foreign keys resolve). The Microsoft Fabric ecosystem supports each of these through standard tools (pytest, Great Expectations, SQL assertions). Mature data teams run all three; ad-hoc teams run none.

There are two main patterns for using market basket analysis rules in cross-sell. Real-time recommendations: when a customer adds A to a basket online or at the till, the system suggests B based on the rules. The implementation requires the rules table to be accessible at transaction time, usually through an API. Batch recommendations: customers who have bought A but not B receive a targeted email or marketing communication suggesting B. The batch pattern is simpler to implement and works well for email-driven businesses. Both patterns produce measurable lift in attach rate when the rules are good.

To visualise MBA rules in Power BI, three views work well. A rule table sorted by lift, showing the top rules with their measures. A network graph showing the strongest associations as edges between items, useful for understanding the structure of the relationships. A category heatmap showing aggregate association strength between categories rather than individual items. The right view depends on the audience: buying teams use the rule table, range planners use the network graph, leadership uses the heatmap. Power BI handles all three.

A single view of pipeline health comes from a central monitoring view rather than checking each pipeline individually. Fabric's monitoring hub gives one place to see every pipeline run across a workspace: its status, how long it took compared with previous runs, and where in the pipeline it failed if it failed. That execution history matters as much as the current status, because a pipeline that succeeds but takes three times as long as usual is an early warning of a problem that has not caused a visible failure yet. On top of that, most pipelines we build include retry logic for transient failures, such as a source system timing out briefly, so a single blip does not require a person to intervene. That is the closest real equivalent of self-healing: automatic recovery from the failure types that are expected and understood, combined with an alert to a person for the failure types that are not.

Each layer is a set of Delta tables in dedicated lakehouse workspaces or schemas. Bronze tables are append-only with transaction timestamps. Silver tables are mutable with merge logic for deduplication. Gold tables are typically rebuilt or merged depending on the modelling pattern. Direct Lake mode in Power BI reads Gold tables directly without copying. The Delta Lake format provides ACID transactions, schema evolution, and time travel across all three layers. The technology supports the pattern cleanly; the discipline is in the design.

We handle the training-versus-detecting tension in Fabric anomaly detection by treating anomaly detection as a continuously learning system. The model trained on the most recent stable period is used for current detection. As new observations accumulate, they are evaluated against the current model. Confirmed anomalies are excluded from future training data; confirmed normal observations are included. The model retrains periodically (weekly or monthly typically) on the cleaned recent data. This pattern keeps the model adapted to evolving normal behaviour while preserving sensitivity to genuine anomalies.

Training data with embedded anomalies is a real challenge in anomaly detection. Anomaly detection that trains on data containing past anomalies treats them as part of normal, which means similar future events will not be flagged. Two approaches. First, manual labelling: identify and remove known anomalies from the training data before fitting the model. Second, robust techniques (median-based statistics, robust ML methods) that resist contamination by outliers in training data. Both approaches require some manual investment in understanding the historical data. The investment pays back through reduced false negatives in production.

Every pipeline is built with monitoring and alerting from day one, not added afterwards. That means logging at each stage of the pipeline, automated failure alerts rather than someone noticing a report looks wrong, retry logic for transient source-system issues, and data quality checks that run before a load is considered complete. Across the Azure and Fabric pipelines we run for clients, this approach holds an average 96% pipeline reliability rate. We treat a pipeline the same way we treat a report: it needs an owner, a defined expected behaviour, and a way to know quickly when it has drifted from that behaviour.

ADF handles on-premises systems through the Self-hosted Integration Runtime, an agent installed on a server with access to the on-premises systems. ADF in the cloud orchestrates the pipeline; the integration runtime executes the source-side data movement. The model handles secure, performant integration without exposing the on-premises systems to the public internet. For mid-market businesses with significant on-premises data (older ERPs, internal databases, file shares), the integration runtime is the standard pattern. The same pattern applies to Fabric Data Factory.

Fabric is built on Azure infrastructure but presented as an integrated platform with its own pricing model and user experience. Several Azure services have Fabric equivalents: Azure Data Factory has Fabric Data Factory; Azure Synapse has Fabric Data Engineering and Data Warehouse; Power BI Premium is now part of Fabric capacity. The Azure services continue to exist for use cases that need them; the Fabric versions are usually preferred for new analytical workloads. The Fabric for Mid-Market FAQ in our library covers when Fabric is the right choice over assembling Azure components separately.

Data Activator triggers actions when configured anomaly conditions are met. The pattern: the anomaly detection scoring runs continuously or in micro-batches, the scores are written to a stream that Data Activator monitors, and rules evaluate the stream and trigger actions. For high-stakes anomalies, the action is human notification (Teams message, email, ticket creation) for immediate review. For lower-stakes anomalies, the action is logging for periodic review. Data Activator is the operational layer that connects detection to response.

Databricks handles multi-cloud natively. Databricks runs on AWS, Azure and GCP with the same product. If your organisation has workloads across more than one cloud, this is a genuine advantage. Fabric is Azure only and pulls Azure-adjacent workloads with it. Multi-cloud is rarely a small consideration when it applies to you.

Databricks is consumption-based, priced in DBUs (Databricks Units) per workload type. Compute scales when needed and stops when idle. Costs are visible per workload but less predictable per month. For organisations with intermittent workloads, this can be cheaper than Fabric's fixed capacity. For continuously running workloads, Fabric capacity often comes out ahead.

Delta Lake tables in OneLake keep a transaction log and version history for every change, so a pipeline can be pointed back at an earlier point in time and reprocessed deterministically. Combined with version-controlled notebooks or Dataflows Gen2, that history is what makes a genuine end-to-end replay possible rather than just a restore from backup.

Direct Lake mode changes the architecture significantly. Direct Lake reads Power BI data directly from Delta tables in OneLake without import or pass-through. The result combines Import-mode performance with near-real-time freshness because the lake is the storage layer rather than a separate copy. For new Fabric implementations, Direct Lake is the default for most semantic models. The exceptions are models that need calculated columns or complex DAX patterns that Direct Lake does not yet support, in which case Import mode remains the right choice.

Fabric workspaces can be connected to Azure DevOps Git or GitHub repositories. Notebooks, semantic models, pipelines, and reports are stored as code in the repository. Changes are made through pull requests with code review. Deployments to other workspaces (development to test to production) happen through the deployment pipelines feature or through CI/CD automation. The integration is the foundation for serious data engineering practice on Fabric.

Fabric is the productised, integrated path. Raw Azure (ADF plus Synapse plus Power BI plus Storage plus Purview, configured separately) is more flexible but more work. For most mid-market businesses, Fabric's integration advantages outweigh the flexibility gains of raw Azure. For very specific high-volume or specialised workloads, raw Azure still has a place, but those situations are uncommon at mid-market scale. The default for mid-market new builds is now Fabric. Existing investments on Synapse or raw Azure can usually be migrated cleanly into Fabric.

Fabric integrates natively with the rest of M365. Entra ID for identity, Purview for governance, Sensitivity Labels for data classification, Teams for collaboration, Copilot Studio for AI. Power BI is part of the platform, not bolted on. This is the strongest single argument for Fabric in M365-heavy organisations: the integration tax of running anything else compounds over time.

Fabric pricing affects the per-user Power BI cost decision through an interaction that is the most commonly missed cost pattern. On Fabric capacity below F64, every author and viewer of Power BI content still needs a Pro licence (£11 per user per month). At F64 and above, viewers are free; authors still need Pro. The crossover point where F64 becomes cheaper than F8 plus per-user Pro is around 500 viewers at PAYG, around 370 with annual reservations, around 250 with three-year EA discounts. Most mid-market businesses sit below the crossover and should stay there.

Hopton helps you choose between the platforms in two ways. A decision review, two to three weeks at fixed price, where we walk a structured framework with your team and produce a written recommendation. Or, if you have already chosen Fabric, full delivery. We do not deliver Databricks projects ourselves. If Databricks is the right answer, we will tell you and can introduce you to people who do.

Hopton helps you choose between the platforms in two ways. A decision review, two to three weeks at fixed price, where we walk a structured framework with your team and produce a written recommendation. Or, if you have already chosen Fabric, full delivery: architecture, build, governance and training. We do not deliver Snowflake projects ourselves. If Snowflake is the right answer, we will tell you and can introduce you to people who do.

Hopton typically builds MBA as part of a broader customer or product analytics engagement, or as a focused four to six week implementation when the data foundations are in place. The implementation includes the data preparation, the rule generation in Fabric Data Science, the Power BI visualisation, and the activation pattern with the chosen channel (online recommendation engine, email marketing, store planning, range review). The first useful rules are typically available within three to four weeks; the activation takes another two to four weeks.

Hopton typically builds anomaly detection as part of a broader analytics engagement covering finance integrity, operations monitoring, or risk management; or as a focused six to ten week implementation when the data foundations are in place. The implementation includes the data review, the technique selection (statistical versus ML based on the use case), the build in Fabric Data Science, the operational pattern (batch versus streaming), the activation through Data Activator and the existing alerting tools, and the calibration discipline. Working detection is typically running within four to six weeks; full operational integration takes another four to six weeks.

Hopton typically builds demand forecasting as part of a broader supply chain or commercial analytics engagement, or as a focused 8 to 12 week implementation when the foundations are in place. The implementation includes the data review, the technique selection (Prophet versus gradient-boosted versus classical based on the business shape), the build in Fabric Data Science, the validation and accuracy testing, the Power BI visualisation, and the integration with the planning system. Working forecasts are typically available within six to eight weeks; full operational integration takes another four to six weeks.

KQL is more concise for time-series operations, more powerful for pattern matching, and faster on the time-series workloads it was designed for. SQL is more universal, more familiar, and stronger for complex joins across many tables. For an analyst whose work is mostly time-series and event data, KQL pays back the learning investment quickly. For an analyst whose work is mostly traditional dimensional modelling, SQL remains the better tool. Microsoft Fabric supports both well; the choice can be made per use case rather than imposed across the team.

Market basket analysis, RFM, and CLV are complementary techniques. RFM segments customers by behaviour. MBA finds product associations. CLV models customer value over time. Together they form the core of customer and product analytics. Most of our customer analytics engagements deliver RFM first (because the data foundations are usually in place faster), MBA second (because it benefits from the customer-level view), and CLV third (because it needs the most data and is the most sophisticated of the three).

MBA supports range and listing decisions by identifying products that anchor baskets versus products that come along. Anchor products (high lift to many other products) are essential to the range. Pure 'comes along' products (high confidence given other purchases but low independent demand) survive on the back of the anchors. Stand-alone products (high independent demand, low association) survive on their own. The range review meeting becomes data-informed: which products are essential, which are dispensable, which need promoting harder. The conversation moves from anecdote to evidence.

Both are capable data platforms, and both use a lakehouse approach with consumption-based pricing rather than fixed licence tiers. The practical differences are in specialisation and ecosystem fit. Fabric is the better choice for organisations already invested in the Microsoft ecosystem (Power BI, Azure, M365) because the integration is native, the governance model is consistent, and Fabric capacity billing sits alongside your existing Azure consumption. Databricks is often the stronger choice for organisations with heavy Python/Spark workloads, dedicated data or AI engineering teams who want deeper control over the ML lifecycle, or genuinely multi-cloud architectures spanning AWS, Azure, and GCP. We assess which platform fits your specific situation rather than defaulting to a position.

The Fabric forecast is the analytical backbone of the S&OP (sales and operations planning) or IBP (integrated business planning) process. Each cycle, the team starts with the statistical forecast, adjusts for known factors not in the model, and arrives at a consensus plan. Fabric supports the cycle by providing the latest forecast, the historical accuracy data, and the analytical context (recent trends, anomalies, comparisons). The S&OP discipline runs on top; Fabric provides the data foundation.

Real-Time Intelligence is well-suited to IoT workloads. The eventstream ingests device telemetry, the eventhouse stores it efficiently, KQL queries surface patterns, and Data Activator triggers responses. Common patterns: equipment monitoring (predictive maintenance), fleet tracking, asset tracking, environmental monitoring. The architecture supports millions of devices and billions of events. For mid-market businesses with IoT data, the Fabric path is usually cleaner and cheaper than building a custom IoT analytics stack.

Power BI surfaces the forecast for business users through dashboards combining actuals, forecasts, and accuracy. The standard views include: forecast versus actual over time, accuracy metrics by SKU group and horizon, exception views showing SKUs with the largest forecast errors, and the planning view showing the forecast as input to the operational plan. Different audiences use different views: planners use the SKU-level detail, leadership uses the aggregate trends, finance uses the accuracy metrics for forecast credibility. Power BI handles all the views from the same underlying data.

Power BI works well on Databricks. Power BI connects to Databricks SQL through the standard connector and works fine. The integration is solid. The difference compared to Fabric is the same as Snowflake: it is two systems working together rather than one unified system. For BI-led organisations, the integration tax is real but manageable. For organisations where BI is one of many concerns, it is rarely the deciding factor.

Purview integrates natively with Fabric and Power BI. Sensitivity labels applied in Purview propagate to Fabric workspaces, semantic models, and Power BI reports. Lineage tracks data movement across the analytical estate. Classification rules apply consistently. The integration is one of the genuine advantages of staying within the Microsoft ecosystem; equivalent integration with non-Microsoft governance tools requires more work. For Microsoft-stack mid-market analytics, Purview is usually the right governance tool.

Snowflake handles multi-cloud natively. Snowflake runs on AWS, Azure and GCP and supports cross-cloud data sharing. If your organisation has workloads across more than one cloud, this is a genuine advantage. Fabric is Azure only and pulls Azure-adjacent workloads with it. Multi-cloud strategy is rarely a small consideration when it applies.

A real-time engagement differs from a batch one in three ways. The use case definition matters more, because real-time has higher costs and tighter benefits. The architectural design is more complex, with eventstream routing, eventhouse design, and Data Activator rules to specify. The operational model is different, with streaming-specific monitoring and recovery patterns rather than batch retry logic. The engagement timeline can be similar (eight to twelve weeks for a focused real-time implementation) but the discovery and design phases are usually more involved.

Anomaly detection is complementary to the other ML techniques — RFM, MBA, CLV, and forecasting. RFM segments customers; anomaly detection flags unusual customers. MBA finds product associations; anomaly detection flags transactions outside expected patterns. Forecasting predicts expected demand; anomaly detection flags actuals deviating from forecast. The five techniques together cover most of the mid-market ML opportunity. Many of our customer analytics and operations engagements deliver several of them in sequence as the foundations stabilise.

Anomaly detection integrates with your existing alerting tools through Data Activator's flexible action configuration, alerts can route to existing operational tools: ServiceNow for incident management, Teams for collaborative response, email for distribution, Power Automate flows for custom workflow integration, REST endpoints for proprietary tools. The detection runs in Fabric; the action lands wherever the operational team works. The integration model means anomaly detection extends existing workflows rather than requiring teams to adopt new tools.

Anomaly detection supports finance integrity through monitoring of transactional data for unusual patterns. Examples: journal entries outside normal patterns for the user or period, expense submissions outside the user's historical range, supplier payments to unusual destinations, account reconciliations with unusual variances, period-end accruals outside historical ranges. The patterns surface to the finance team for review, supplementing manual review. The technique is particularly valuable for mid-sized finance teams where manual review of every transaction is not feasible.

Fabric is native to Entra ID, Purview and M365 Sensitivity Labels. The governance story is genuinely tighter for organisations already on M365. Snowflake supports the same integrations but they are plumbed in rather than built in. The difference is operational rather than functional. Day-to-day, Fabric requires fewer touchpoints. For organisations with mature governance functions, the difference is smaller. For organisations relying on out-of-the-box governance, it is larger.

Both Fabric and Databricks are lakehouse platforms and handle the lakehouse architecture similarly. Databricks invented the term and the architecture. Fabric implements lakehouse via OneLake using Delta as the storage format. The architectures are functionally similar. The differences are in tooling, governance and the surrounding ecosystem. Both let you store once and query many ways. The platform decision is rarely about the lakehouse architecture itself.

Governance works in Fabric through Microsoft Purview, integrated natively with Fabric, plus three governance layers we configure explicitly: access models, regional deployment, and security alignment. Sensitivity labels, data classification, lineage tracking, and access governance all run through Purview, and Fabric workloads inherit that configuration automatically. Access models are workspace-based: read, write, and admin roles are assigned per workspace, with row-level security layered on top for report-level restriction. Regional deployment matters because a Fabric capacity is pinned to an Azure region at creation and cannot be moved later, so data residency and region are agreed before provisioning, not after. Security alignment covers tenant-level settings (external sharing, guest access, capacity admin roles) plus Entra ID conditional access, agreed with your IT and security team before go-live. The integration is meaningful: previous Microsoft data platforms required separate governance configuration for each component, and the discipline often slipped. Fabric centralises it. Purview setup, access model design, and regional and security sign-off are all part of the Establish phase in our standard implementation, not an afterthought.

Real-time fits alongside existing batch analytics through a unified architecture where batch and streaming feed the same lakehouse, with each workload using the data through whichever path suits the latency requirement. Batch analytics reads Gold-layer Delta tables for traditional reporting. Real-time analytics queries eventhouses for streaming dashboards and Data Activator for event-driven actions. The two coexist on the same Fabric capacity, sharing storage in OneLake, sharing governance through Purview, and sharing identity through Entra ID. Real-time is an extension of the platform, not a separate platform.

Real-time fraud detection works through Data Activator rules monitoring transaction streams for patterns that indicate fraud. The patterns are usually combinations: unusually high transaction amount, unusual location, unusual time, or unusual frequency relative to the customer's history. When the rule triggers, Data Activator routes the event to the fraud team for review or, in tightly-scoped automated cases, takes immediate action (hold the transaction for review). The trust framework matters here particularly: false positives cost customer relationships, false negatives cost actual money. Conservative threshold setting and human review on the marginal cases is the right pattern.

The Power BI/Fabric forecast integrates with your planning system as an input rather than a replacement: most mid-market businesses with serious supply chain operations use a dedicated planning system (RELEX, Anaplan, o9, Slimstock, similar) for the actual planning workflow. The Fabric forecast feeds the planning system as input. The pattern: Fabric generates statistical forecasts, the planning system adds management adjustments, the result becomes the operational plan. The integration is bidirectional: actuals flow back from the planning system into Fabric for accuracy tracking and model refinement. The integration architecture is straightforward but requires deliberate design.

The trust framework applies strongly to demand forecasts. Demand forecasts are model outputs going into operational decisions, often automated ones (replenishment orders, production schedules). The Model Trust One-Pager from our AI/ML whitepaper applies directly: every forecast should travel with sources, freshness, limits, confidence, recommended action, and change history. The 'limits' block matters particularly because forecasts are weakest in exactly the situations where the operational risk is highest (new products, promotional events, regime changes). Hiding the weakness produces operational disasters; surfacing it produces sensible decisions.

How important notebook-native development is depends on your team. For engineers who live in notebooks, it is core. For analysts who live in BI tools, it is rarely used. If notebooks are the daily working environment for more than a few people on your team, Databricks fits better. If notebooks are an occasional tool for a small group, Fabric's notebooks are sufficient.

CDC is implemented in Microsoft Fabric through Fabric Data Factory pipelines that consume change streams from source systems and write incremental updates to Bronze. The destination Bronze tables append the change records with metadata (timestamp, operation type, source identifier). Silver layer transformations apply the changes to produce the current-state view. The pattern preserves the change history in Bronze (useful for audit and recovery) while presenting the consumed Silver view as the working state. Mature CDC implementations also support point-in-time queries through Delta Lake's time travel.

Fabric capacity for mid-market is priced as F-SKU capacity, from F2 (around £200 per month) to F2048 for enterprise workloads. Mid-market implementations typically start on F8 (around £1,050 per month) or F16 (around £2,100 per month) for production. F64 (around £6,400 per month) becomes economical when viewer counts exceed roughly 500 because free Power BI viewing kicks in at that tier. The True Cost FAQ in our library covers the licensing economics in detail, including the five overspending patterns we see most often.

MBA is implemented in Fabric Data Science through a Fabric Data Science notebook reading transaction data from the lakehouse. The standard implementation uses Python with the mlxtend library, which provides Apriori and FP-Growth as ready-to-use functions. The notebook prepares the data (typically as a binary item-presence matrix or list-of-items format), runs the algorithm, filters the rules by support, confidence, and lift thresholds, and writes the rules back to the lakehouse as a Delta table. Power BI semantic models read the rules table for reporting and activation.

OneLake is the unified storage layer underneath every Fabric workload. One copy of the data, in open Delta format, accessible by all Fabric tools without copying or moving. This is genuinely different from previous Microsoft data platforms where Power BI had its own storage, Synapse had its own, and integrations meant duplicating data. The 'one copy' principle reduces storage cost, simplifies governance, and removes the synchronisation work that previously consumed engineering time. For most mid-market implementations, OneLake is the architectural feature with the highest practical impact.

Type 2 SCD is implemented in Microsoft Fabric through MERGE operations in Delta Lake (using SQL or Python notebooks) that compare incoming records to current dimension state, insert new versions when attributes change, and update effective-date and current-flag columns. The pattern is well-established and there are reusable code templates. The implementation is more involved than Type 1 (which is a simple overwrite) but the effort is bounded; once built, the same pattern handles all Type 2 dimensions in the platform.

Anomaly detection is built in Microsoft Fabric through Fabric Data Science notebooks for the modelling, with deployment patterns ranging from scheduled batch evaluation to streaming evaluation through Real-Time Intelligence. The standard implementation: a notebook trains the model on historical data, persists it, and runs scoring as a scheduled pipeline against new data. Anomaly scores are written to a Delta table in the lakehouse.

Threshold alerts fire when a value crosses a fixed boundary (revenue below £100k, response time above 2 seconds). Anomaly detection learns what 'normal' looks like and flags deviations from that pattern. The difference matters because thresholds work for one-dimensional, stable metrics; anomaly detection works for complex, multi-dimensional, or seasonally varying patterns. Threshold alerts on retail revenue would fire false alarms every quiet Tuesday and miss the anomaly of a Christmas Eve dropping 30 per cent below expected. Anomaly detection adapts to the pattern.

Demand forecasting is built in Microsoft Fabric through Fabric Data Science notebooks reading historical demand data from the lakehouse. The notebooks fit forecasting models (Prophet, gradient-boosted regression, ARIMA depending on the use case), generate forecasts for the relevant horizon, and write the forecasts back to the lakehouse as a Delta table. Power BI semantic models read the forecasts for reporting alongside actuals. The pipeline runs on schedule (typically weekly) so the forecasts stay current. The architecture is consistent with the broader Bronze/Silver/Gold pattern.

Demand forecasting predicts what customers want; sales forecasting predicts what will be sold. The two diverge when supply constraints, stock-outs, or pricing decisions affect what actually gets sold. A pure-play retailer with available stock has demand and sales aligned. A retailer with frequent stock-outs has demand exceeding sales for the missing periods. The distinction matters because demand forecasts should drive supply decisions independently of past sales constraints. Sales-only forecasting can produce a self-reinforcing cycle of under-stocking. Demand forecasting models, properly built, account for stock-out periods and predict the underlying demand.

Real-time differs from batch in three structural ways, from a data engineering point of view. Batch processes accumulated data on schedule; streaming processes individual events as they arrive. Batch tolerates failure with retry; streaming requires careful state management to avoid losing or duplicating events. Batch performance is measured in throughput; streaming performance is measured in latency. The skills, the tools, and the operational model differ. Most data engineering teams need to learn streaming separately from batch; they are not interchangeable.

A modern lakehouse differs from a traditional data warehouse in three structural shifts. Traditional warehouses combined storage and compute in a single appliance; modern lakehouses separate them, storing data once in cloud object storage and applying compute on demand. Traditional warehouses kept only structured business-ready data; lakehouses keep raw data alongside transformed data, supporting machine learning and exploration alongside reporting. Traditional warehouses were schema-on-write (transformations happened on the way in); lakehouses are schema-on-read or hybrid, allowing schema evolution without rebuilding the warehouse. Each shift reduces operational pain and increases flexibility.

A Fabric implementation in mid-market takes eight to twelve weeks for a production-ready first release covering the priority reporting domains. Three to six months for a full estate including all priority workloads, governance, and adoption work. The eight-to-twelve week figure assumes a focused engagement with prioritised reporting needs and a working Microsoft estate underneath. Stretched implementations (multiple competing priorities, scope creep, parallel workstreams) take longer. The Establish phase (typically four weeks) sets the architecture and the priorities before the build phase starts.

A Fabric lakehouse or warehouse implementation, including pipelines, governance, and Power BI integration, typically takes ten to sixteen weeks in the Build phase. Migrations from existing platforms depend on the complexity of the current estate. The Establish phase (four weeks) always precedes the Build to define the architecture and scope precisely.

How long a Microsoft Fabric implementation takes depends on scope, and it should be incremental rather than a single migration. A focused pilot typically takes around 4 to 8 weeks, a mid-sized deployment across several subject areas around 3 to 6 months, and a full enterprise migration around 9 to 18 months. The biggest drivers of timeline are governance complexity, migration scope and data quality, testing and reconciliation, and change management — not the technology itself.

The decision phase should take two to four weeks for most mid-market organisations. Longer for larger or more complex situations. The trap is letting the decision phase drag for months while the team debates internally. Set a fixed timeline, run a structured framework, and commit to a decision. Indecision costs more than a slightly imperfect choice.

The number of rules MBA produces is variable, controlled by the thresholds. With permissive thresholds (low minimum support and confidence), MBA can produce thousands or tens of thousands of rules, most of them not commercially useful. With strict thresholds, the rule count drops to hundreds or tens. The right thresholds depend on the business: a 50,000-SKU retailer needs different thresholds than a 500-SKU specialist. The pattern that works is to start permissive, observe the rule distribution, and tighten the thresholds until the output is the right size to act on.

A data pipeline has no fixed number of transformation steps, but most well-run Fabric estates settle on four: landing raw data untouched, conforming it into a consistent shape, applying business logic once, and serving it through a semantic model. Fewer steps usually means logic is being duplicated somewhere it shouldn't be, and many more often means the pipeline is solving problems that belong in governance rather than transformation.

Demand forecasting needs three years of history as the recommended minimum, five years as the comfortable target. Three years captures typical seasonal patterns and enough variation for the models to learn. Two years works for stable businesses but produces less reliable forecasts for the seasonal periods near the boundaries of the history. Less than two years makes proper seasonal forecasting difficult; the techniques work but the accuracy is materially lower.

Market basket analysis needs at least six months of transaction history for stable rules, ideally a year or more. The technique needs enough transaction volume to produce statistically meaningful associations. A retailer with one million transactions per year produces good rules on six months of data; a B2B business with ten thousand transactions per year needs years to find similar patterns. The threshold is transaction volume rather than time. Below roughly 50,000 transactions, MBA produces unstable rules that change between runs; above that, the rules stabilise.

Across our engagements, automated Azure and Fabric pipelines run at a 96% average reliability rate, meaning scheduled refreshes complete successfully without manual intervention in the large majority of runs. We get there through standard engineering discipline rather than luck: retry logic on transient failures, alerting the moment a pipeline fails rather than letting it fail silently, and reconciliation checks that catch data quality problems before they reach a report. Pipeline reliability is monitored from the first week of go-live, not assumed.

Snowflake works well with Power BI, but as two systems. Power BI connects to Snowflake via the standard connector and works fine. The integration is solid. What you do not get is the unified experience Fabric provides: shared semantic models, shared identity, integrated lineage. For most mid-market workloads, that integration tax is real but manageable. For BI-led organisations, the tax adds up over time.

Databricks is better for engineering teams if engineering means code-first, version-controlled, notebook-led work. Databricks gives engineers an environment that feels familiar. Fabric is improving on this front but the visual designers are still the centre of the experience. Engineering-led organisations tend to find Databricks lower friction. The tipping point is roughly when more than half your team writes code daily.

Databricks is not just for big data anymore. Databricks Serverless SQL and the wider product investments have made it credible for mid-market workloads. The historic perception that Databricks was only for large enterprises with Spark engineering teams is out of date. Cost is no longer a knock-out for mid-market. The remaining question is whether the platform's centre of gravity (code-first, notebook-led) suits how your team actually works.

Fabric is generally better for analyst-led teams. Fabric's visual designers, low-code paths and Copilot integration are genuinely strong for analyst-led work. Databricks is improving here but the centre of gravity remains code-first. If your team includes more analysts than engineers, Fabric reduces friction. If your team is engineer-heavy, Fabric can feel constraining.

Fabric is not just a rebadged Synapse, though the marketing makes it tempting to think so. Synapse components are inside Fabric, but the experience, governance, BI integration and capacity model are genuinely new. Treat Fabric on its own merits rather than judging it by Synapse's history. Several of the friction points that affected Synapse have been addressed in Fabric.

Fabric is sometimes over-specified for specific use cases, but rarely overall, at mid-market data volumes. Fabric is sized to scale up to enterprise workloads, but the entry tier (F2 capacity at around £200 per month) is genuinely affordable for mid-market and gives you the full platform capability at low volume. The scale headroom is useful as the business grows; the low entry point makes the start manageable. The cost concern in mid-market Fabric is rarely 'is this too much capacity'; it is 'is the per-user Power BI Pro licensing being properly managed alongside the capacity'. The True Cost FAQ in our library covers this in detail.

Fabric is ready for production workloads for most mid-market workloads. Fabric has been generally available for over a year and the components inside it are mature. The integrated experience is newer than the parts. There are still edge cases where the integration is incomplete, but for the workloads most mid-market organisations run, Fabric is production-ready. We have multiple clients on Fabric in production today.

Yes — Microsoft Fabric is ready for mid-market production use. Fabric reached general availability in late 2023 and has been in production across our client base since 2024. The platform is mature enough for mission-critical workloads when implemented properly. The early adopter risks (feature gaps, version churn, performance unpredictability) have largely settled. The remaining decision is not whether Fabric is ready but whether it is the right fit for your specific situation. For most mid-market businesses on the Microsoft stack, the answer is increasingly yes.

On warehouse-shaped workloads, Snowflake is often faster than Fabric. On the round trip from raw data to a dashboard a business user opens, less often. The benchmark wars are real but mostly relevant at scale most mid-market businesses do not reach. For a typical mid-market workload, both platforms are fast enough. The performance difference matters most when you are running enterprise-scale analytical queries continuously.

Fraud detection is one application of anomaly detection. Not all anomalies are fraud (a genuine extraordinary transaction is also anomalous), and not all fraud is anomalous (sophisticated fraud may look normal). The right framing is that anomaly detection surfaces unusual events, and human judgement determines whether the unusualness indicates fraud, error, exception, or legitimate variation. The technique supports fraud detection workflows but is not a complete fraud system on its own.

Demand forecasting is an ongoing capability, not a one-off project. Demand patterns evolve, new products launch, ranges change, market conditions shift. A one-off forecast is useful for the moment it is built and then degrades. The right framing is to build demand forecasting as a capability with regular refresh, monitoring, and accuracy tracking. The implementation is a project; the ongoing operation is a discipline. Most of our demand forecasting engagements include the ongoing operational pattern alongside the initial build.

Modern data architecture is less of an overkill for mid-market businesses than buyers usually expect. The architectural patterns scale down as well as up. A mid-market business does not need every component of an enterprise data platform, but the principles (separation of concerns, version-controlled pipelines, deliberate medallion layering) apply at every scale. The cost of doing it properly is moderate; the cost of doing it badly compounds quickly. Mid-market data platforms built without architectural discipline tend to need rebuilding within three to five years; platforms built with discipline keep growing.

Yes — real-time analytics is often overkill for mid-market businesses. The honest assessment for many mid-market businesses is that 'real-time' requirements turn out to mean 'within an hour' or 'within a day', which standard batch refresh patterns handle. The cost of building real-time architecture (development effort, infrastructure cost, operational complexity) is substantial; the cost should be justified by genuine business need rather than by the technical novelty. We have built real-time platforms for clients where the use case justified it; we have also recommended against real-time investment for clients where batch was sufficient.

For most mid-market workloads, the Fabric, Snowflake and Databricks comparison is a fair fight rather than one platform being obviously better. There are scenarios where one is obviously better and we cover those in the deck. Pure data warehouse performance at extreme scale tends to favour Snowflake. BI-led organisations on M365 tend to favour Fabric. In between, the decision is genuine and depends on your situation more than on the platforms.

Use a Lakehouse for most cases. The Lakehouse stores Delta tables in OneLake, which all the other Fabric workloads can read directly. It supports notebooks (Python, Spark) for transformation and runs Power BI semantic models with Direct Lake mode for high-performance reporting without copying data. The Warehouse is better when your team works in SQL exclusively, when you have specific T-SQL requirements, or when performance characteristics demand it. Most mid-market implementations use the Lakehouse as the default with the Warehouse for specific workloads.

Snowflake excels at elastic, multi-cloud SQL warehousing and data sharing. Databricks leads for large-scale data engineering and machine learning on the lakehouse. Microsoft Fabric excels when you are Microsoft-centric and want data integration, warehousing, governed self-service BI in Power BI, and AI in one platform rather than integrated afterwards. Choose by your dominant workload — warehouse-first, ML-first, governance-heavy, or multi-cloud — rather than by brand.

For MBA in Fabric, use Python with mlxtend for most mid-market implementations. The data volumes are usually manageable on a single notebook instance. Spark with MLlib is the right choice for very large transaction volumes (hundreds of millions of transactions or more) where the parallelism matters. The output format and the rule interpretation are the same regardless of the implementation. Most retailers and wholesalers we work with run successful MBA on Python without needing Spark.

For forecasting in Fabric, use Python for most mid-market implementations. The data volumes per SKU are usually moderate, and Python on a Fabric Data Science notebook handles thousands of independent time-series comfortably. Spark with MLlib becomes worthwhile at very large scale (tens of thousands or hundreds of thousands of SKUs forecast simultaneously). The output format is the same; the implementation choice is mostly about scale. Most mid-market retailers and wholesalers run successful forecasting on Python without needing Spark.

Most mid-market implementations use batch CDC at intervals of minutes to hours. Real-time CDC (where changes flow continuously into the platform) is achievable through Fabric's eventstreams and Real-Time Intelligence workload but is overkill for most analytical use cases. The right interval depends on the business need: customer-facing operational dashboards may justify minute-level CDC, monthly management reporting works fine on overnight CDC. Choose deliberately rather than defaulting to real-time.

Anomaly detection should run almost always with human review for the actions that matter, rather than fully autonomously. The pattern that works: the system flags anomalies and routes them to a human queue for review, the human confirms or dismisses, and the action follows the human decision. Fully autonomous anomaly response is appropriate only for narrow well-defined cases where false positives are cheap and the response is easily reversible. The Trust Storytelling framework applies particularly here: anomaly detection outputs going into operational decisions need provenance, freshness, and explicit limit framing.

Whether anomaly detection should run in batch or real-time depends on the use case. Finance integrity work usually runs in batch (overnight or weekly review of recent transactions). Operational monitoring usually runs in real-time or near-real-time (the value is in catching the issue while it is still recoverable). Customer behaviour monitoring varies. Most mid-market implementations include both: batch detection for periodic review with deeper analysis, and real-time detection for high-stakes immediate response. The Fabric architecture supports both within the same platform.

Data should be transformed after it lands in Fabric, as a general rule. We extract and load first, raw and unaltered, into the bronze layer, rather than transforming data in flight before it arrives. This matters practically: if a transformation rule turns out to be wrong, the original data is still there to reprocess from, rather than already overwritten by a flawed transformation on the way in. Transformation happens afterwards, moving data from bronze to silver to gold inside Fabric itself, where it is easier to test, version and fix. For on-premises source systems, such as an on-site SQL Server or an ERP database that is not internet-facing, a self-hosted integration runtime acts as the bridge: a lightweight agent installed inside your network that lets Fabric pipelines reach that data securely without opening the source system directly to the internet. This is the standard pattern for hybrid estates where some systems are cloud-based and others are not.

For new analytical platform investments, Fabric is usually the right choice. The integration advantages outweigh the flexibility losses for typical mid-market workloads. For specific use cases (high-volume custom data engineering, specialist AI workloads, integration with non-Microsoft systems where Azure connectors are stronger), the underlying Azure services may be the better fit. Most mid-market businesses end up with a mix: Fabric for the analytical estate, with specific Azure services where they add value. The architecture decision should follow the use case rather than picking a platform first.

Real-time data should sometimes be stored separately from batch data, depending on the use case. High-volume time-series data (IoT, application logs, audit events) lives best in eventhouses with Kusto-style optimisation. Streaming data that needs to be combined with batch data for unified reporting lives best in lakehouse Delta tables. Many real-time implementations route the same source events to both, with the eventhouse serving real-time queries and the lakehouse serving combined batch and streaming analytics. The decision is per source; the architecture supports both patterns.

You should forecast at both SKU and aggregate level, with reconciliation. SKU-level forecasts inform stock decisions; aggregate forecasts (category, total) inform broader planning and reconcile against expected revenue. Independent SKU and aggregate forecasts often disagree (the SKU forecasts add up to a different total than the aggregate forecast). Hierarchical forecasting techniques (using libraries like hts) reconcile the levels mathematically. For most mid-market businesses, simpler approaches (forecast at the most useful level, use management judgement to reconcile) work well enough.

For most mid-market organisations, migrating from Azure Synapse to Microsoft Fabric makes sense - but the timing and approach depend on your current investment. Fabric supersedes Synapse Analytics and Microsoft has signalled it is the strategic direction for the platform. The migration path is well-defined for most workloads. We assess the specific components you are using, the dependencies involved, and the right sequencing before recommending a migration approach.

For most mid-market Synapse customers, yes, eventually. Fabric is Microsoft's strategic direction for the data and analytics platform; Synapse is in maintenance rather than active development. New investments should go into Fabric, and existing Synapse workloads should be migrated as the right opportunities arise (renewals, refresh cycles, major project moments). The migration from Synapse to Fabric is well-documented and usually less work than the original Synapse build.

Starting with a forecasting proof of concept is often the right move. A four-week proof of concept on a representative SKU subset produces real forecasts on real data, validates the technique choice, and demonstrates the achievable accuracy. The proof of concept output is usable directly for some decisions and informs the scoping of the full implementation. We have run forecasting proof of concepts that became permanent operational forecasts because the accuracy was strong enough to act on without additional implementation effort.

Copilot in Fabric is genuinely ahead of Databricks Genie for analyst-led use. Natural language to DAX, Copilot in Power BI, semantic-model-aware AI assistants: this is where Microsoft's broader AI investment shows up first. For organisations whose AI ambition is mostly about analyst productivity and BI augmentation, Fabric has the lead today.

Copilot and Databricks Genie are both AI assistants for data work. Copilot in Fabric is more mature for analyst-led, BI-shaped use. Databricks Genie is improving and benefits from the broader AI investment Databricks has made. For organisations whose AI ambition is mostly analyst productivity, Copilot is ahead. For organisations doing serious ML and looking for AI-assisted engineering, Databricks is closing fast.

Unity Catalog is Databricks' answer to data governance and is genuinely strong. Fabric uses Purview for the same role. Both work. Unity Catalog is more tightly integrated into Databricks itself. Purview integrates with the wider M365 estate. Which is better depends on whether your governance perimeter is the data platform or the wider Microsoft estate.

Deep learning for forecasting is useful in specific scenarios. Deep learning models (DeepAR, Temporal Fusion Transformer, N-BEATS) handle very large numbers of related time-series simultaneously with shared learning across them. The technique pays back when you have many SKUs (thousands or tens of thousands) with related patterns. For mid-market businesses with smaller SKU counts, deep learning is usually overkill; gradient-boosted regression or Prophet produces comparable accuracy at a fraction of the complexity.

Real-time intelligence in Fabric is available, but used selectively in mid-market. The Real-Time Intelligence workload supports streaming data from event sources (IoT devices, application telemetry, transactional systems) with KQL-based analytics on top. The use cases that pay back are narrow: live operational dashboards where the value is in seconds rather than minutes, anomaly detection on fast-moving data, and event-driven workflows. Many mid-market 'real-time' requirements turn out to mean 'within an hour', which is usually fine on standard Fabric refresh patterns rather than streaming.

Anomaly detection techniques fall into three main categories. Statistical methods (control charts, Z-scores, MAD-based scoring) which are simple, interpretable, and effective for univariate or weakly-multivariate data. Machine learning methods (isolation forest, one-class SVM, autoencoder-based) which handle multivariate and complex patterns. Hybrid methods combining the two for specific use cases. Each has its place. Most mid-market implementations start with statistical methods because they are interpretable and easy to deploy, then layer on ML methods for use cases where the statistical approach is insufficient.

Slowly changing dimensions (SCDs) are dimensions whose attributes change over time, requiring deliberate handling to preserve historical accuracy. A customer changes address, a product changes category, an employee changes department. Without SCD handling, historical reports look correct but use current attributes for all periods, producing subtly wrong answers (the customer's December purchase shown against their February address). SCDs are one of the most important and most often skipped data architecture concerns. Getting them right is part of a serious modern data architecture.

Support, confidence, and lift are three measures of how meaningful a rule is. Support is the proportion of all transactions containing both items: high support means the combination occurs often. Confidence is the proportion of transactions containing item A that also contain item B: high confidence means B reliably follows A. Lift is the ratio of observed confidence to the baseline frequency of B: lift greater than 1 means A increases the likelihood of B; lift below 1 means A decreases it. Useful rules typically have lift well above 1, confidence above some practical threshold, and support high enough to be worth acting on.

There are six Fabric workloads. Data Factory for integration and pipelines (used in every implementation). Lakehouse for analytical storage with notebook-based transformation (used in most). Data Warehouse for SQL-based analytics (used where the team prefers SQL to Spark). Real-Time Intelligence for streaming and event data (used where genuinely needed, less common in mid-market). Data Science for ML (used in maybe a third of mid-market implementations). Power BI for visualisation (used in every implementation). Most mid-market Fabric estates run heavily on Data Factory, Lakehouse, and Power BI, with the others added as the use cases emerge.

There are six SCD types. Type 1 overwrites the attribute with the latest value (no history kept). Type 2 inserts a new row for each change with effective dates (full history). Type 3 keeps current and previous values in separate columns (limited history). Type 4 stores history in a separate table. Type 6 combines Type 1, 2, and 3 in one table. Most mid-market implementations use Type 1 for non-historical attributes and Type 2 for attributes that need full history. Type 3 and beyond are specialist patterns for specific cases.

Five migration risks come up repeatedly when moving to Microsoft Fabric, and we plan for each explicitly before a migration starts. Unsupported features: some Synapse and Power BI Premium capabilities do not have a direct Fabric equivalent yet, so we check your existing estate against current feature parity before committing to a timeline. Redesign requirements: pipelines and semantic models built for the old platform usually need genuine rework, not a lift-and-shift, particularly around Direct Lake and medallion layering. Dependency inventorying: every report, dataset, pipeline, and downstream consumer is catalogued before anything is touched, because the most common migration failure is breaking something nobody realised depended on the source system. Rollback planning: every migration phase has a defined rollback point, so a failed cutover does not take live reporting down with it. Reconciliation testing: before any workload goes live on Fabric, its output is checked against the legacy system at the row level, not just visually, until the numbers match exactly. None of this is unique to Fabric, but skipping it is the single biggest cause of migrations that overrun on time and budget.

Demand forecasting needs historical demand or sales by item per period at minimum. The granularity depends on the use case: daily for short-cycle retail, weekly for most retail and consumer goods, monthly for industrial. Additional data improves accuracy: pricing history, promotional history, channel breakdown, stock-out flags, marketing spend, weather data for weather-sensitive categories. The minimum dataset produces a working forecast; the richer dataset produces a more accurate one. Most ERPs and ecommerce systems carry the minimum; the additional data often requires integration work.

Anomaly detection needs historical observations of the metric or pattern being monitored. The volume needs to be high enough for the technique to learn what normal looks like: typically thousands of observations for univariate statistical methods, tens of thousands for multivariate ML methods. The history needs to span at least one full cycle of any seasonality (annual cycles need at least one year of data). Additional features (context, dimensions, related metrics) improve the precision of multivariate methods. Most operational and financial systems carry sufficient data for anomaly detection; the bottleneck is usually the modelling decisions rather than the data.

Market basket analysis needs two columns at minimum: transaction identifier and item identifier, with multiple rows per transaction (one per item in the basket). For richer analysis, additional columns help: customer identifier (for personalised rules), date (for temporal analysis), store or channel (for context-specific rules), price and quantity (for value-aware rules). The minimum dataset is small but the richness of the analysis grows with additional columns. Most ERPs and ecommerce systems carry the necessary data already.

Azure cost for mid-market data work is variable, because the services are consumption-priced. Typical mid-market Azure data spend ranges from around £1,000 per month for a modest implementation (small ADF environment, small Azure SQL database) up to £10,000 or more per month for a substantial estate. Reservations and Enterprise Agreements reduce list prices materially (typically 20 to 41 per cent for committed usage). The True Cost FAQ in our library covers the licensing economics; this FAQ covers the architectural choices that determine which services you actually need.

CI/CD means continuous integration and continuous deployment: automated testing and release of changes to the data platform. CI runs validation tests on every pull request (does the pipeline still work, does the model still load, do the measures still produce expected outputs). CD automates the promotion of approved changes through development, test, and production environments. The pattern reduces deployment risk, increases release frequency, and makes the platform more responsive to business needs. CI/CD is the engineering operating model that distinguishes mature data teams from ad-hoc ones.

Databricks is a cloud lakehouse platform built around Apache Spark. It runs notebooks, ML workflows, SQL warehouses and data engineering pipelines. It runs on AWS, Azure and GCP. Databricks champions open table formats (Delta, Iceberg) and an open architecture. The historic strength has been ML and data engineering. The recent investment has been in SQL and BI to compete more directly with Fabric and Snowflake.

Fabric is usually cheaper at mid-market scale once integration costs are factored in. Buying ADF, Synapse, Power BI Premium, and Storage separately produces a list-price total similar to or higher than equivalent Fabric capacity, with significantly more configuration work. The integration tax is real: separate components require integration engineering, separate governance, and separate operational overhead. Fabric removes that. For mid-market businesses, the all-in cost of Fabric is usually lower than the all-in cost of equivalent capability assembled from separate Azure components.

Fabric cost is capacity-based. You buy a capacity tier (F2, F4, F8, and so on) and run workloads against it. Costs are predictable per month, less so per query. Mid-market organisations typically land on F4 or F8 for production, costing several hundred to a few thousand pounds a month. Power BI Premium licences flow into Fabric capacity, so existing investment is not lost.

Fabric is an integrated platform combining data warehousing, lakehouse, data engineering, real-time intelligence, data science and Power BI under one capacity model. It is Azure-only and tightly integrated with M365. The components were previously separate (Synapse, Power BI Premium, Data Factory) and Microsoft has unified them under one billing and governance model.

Snowflake is a cloud data warehouse that has expanded into a broader data platform. It separates storage and compute, runs on AWS, Azure or GCP, and is known for elastic scaling. It also handles data engineering, data sharing, and increasingly data science workloads. Snowflake is platform-neutral about your BI tool: Power BI, Tableau, Looker, and others all work on top.

Snowflake cost is consumption-based. You pay for compute when queries run and storage for data at rest. Costs are visible per query, less predictable per month. Mid-market organisations often land on a few hundred to a few thousand pounds a month, depending on workload patterns. Spiky workloads can be cheaper than fixed Fabric capacity. Steady workloads are often more expensive.

A Fabric implementation in mid-market delivers a unified analytics platform with one storage layer (OneLake), one compute model (Fabric capacity), and one governance layer (Purview). The workloads sit on top: data integration through Data Factory, lakehouse and warehouse for analytical storage, real-time intelligence for streaming, data science for ML, Power BI for visualisation, and Data Activator for event-driven actions. The integration is what differentiates Fabric from buying these components separately. Organisations using Fabric get a coherent platform; organisations using the components separately get an integration tax.

A data engineering consultancy delivers six things in our engagements: warehouse and lakehouse design using proper schemas rather than a flat data dump, cloud platform build on Azure or Microsoft Fabric sized to what the business actually needs, automated integration pipelines that pull data from ERP, CRM and other source systems on a schedule rather than by hand, governance built into the platform from day one including cataloguing, lineage and access control, semantic modelling that translates raw tables into business terms analysts can use directly, and migration work for businesses moving off legacy warehouses or another cloud. The output is a governed analytics layer your own team can run and extend, not a black box that depends on the consultancy to touch it again.

A data engineering engagement with Hopton covers more than pipeline code. A typical engagement starts with an assessment of the current estate, moves through a migration plan for the workloads being moved onto Azure or Fabric, adds a governance layer built on Microsoft Purview for classification and lineage, and ends with a modernisation path that retires the parts of the old stack that no longer earn their cost. The architecture document produced during the Establish phase ties these together in writing: which Azure services are used and why, the cost model, the security posture, and the operational model for running it day to day. That operational model is where cost optimisation and workload tuning live in practice - right-sizing capacity, monitoring spend against actual usage, and re-tuning pipelines and Eventstream jobs as data volumes grow, rather than treating cost as a one-off sizing exercise at kickoff. Security governance is not bolted on afterwards either: sensitivity labels, access boundaries, and audit logging sit inside the same Purview-based governance layer used across Data Factory, Data Lake Storage, and the Fabric lakehouse, so the whole estate is governed consistently instead of pipeline by pipeline.

A typical Microsoft Fabric implementation runs phase by phase. Establish (weeks 1 to 4): discovery of source systems, priority reporting domains, architecture design, capacity sizing, governance approach, written delivery plan. Build (weeks 5 to 12 typically): Bronze layer extractions, Silver layer transformations, Gold layer business models, certified semantic models, priority reports, governance configuration. Adoption (weeks 12 to 16): training, change management, the Trust Storytelling Delivery Checklist applied to executive outputs, Decision Adoption Rate baseline. Continuity is the optional ongoing engagement after launch.

An end-to-end machine learning workflow inside Microsoft Fabric stays in one environment rather than moving data between separate tools for each stage. Data already sits in the lakehouse's silver or gold layer, so a notebook can read it directly using Spark, without a separate export step. Experimentation happens in that same notebook: Fabric's built-in MLflow tracking logs every run automatically, so different feature sets or model versions can be compared without a data scientist building their own tracking spreadsheet. For standard problems, AutoML can test a range of algorithms against the training data and return the best-performing candidate rather than requiring every model to be hand-coded from scratch. Once a model is selected, it is registered in the same workspace and can be called from a notebook, a pipeline, or scored directly against the same lakehouse tables it was trained on. The output, a prediction or a score, lands in a gold-layer table like any other governed dataset, so it inherits the same row-level security and appears in Power BI through the same certified semantic model as everything else, rather than as a separate AI report bolted on afterwards. This matters more than the individual tools: the reason to run machine learning inside Fabric rather than a separate platform is that the model's output stays inside the governance boundary already built, instead of becoming a new, ungoverned data source of its own.

An operational real-time dashboard is live views of operational KPIs refreshed continuously rather than on schedule. Examples include call centre dashboards showing live queue depth and agent status, warehouse dashboards showing live picking rates and order status, retail dashboards showing live till activity by store, and supply chain dashboards showing live shipment positions. The value is the ability to act on developing situations: a queue building, a warehouse falling behind, an unusual sales pattern emerging. Power BI dashboards on Direct Lake against eventhouse data deliver the live view.

Data observability covers pipeline health monitoring (are jobs running on schedule and succeeding), data quality monitoring (is the data arriving with expected characteristics), lineage tracking (where did this data come from and what transformations did it pass through), and freshness monitoring (is the data current). Microsoft Purview provides several of these capabilities natively for Fabric. Third-party tools (Monte Carlo, Soda, Great Expectations) extend the coverage. Observability is the operational discipline that distinguishes data platforms that work reliably from platforms that suffer recurring outages.

Data orchestration means coordinating the execution of data pipelines: when each pipeline runs, what it depends on, how failures are handled, how the orchestration recovers when something breaks. Fabric Data Factory provides the orchestration layer with pipeline definitions, scheduling, dependency management, and monitoring. The orchestration is what makes the data platform reliable: pipelines that run individually in isolation are fragile; orchestrated pipelines with proper dependencies and recovery are robust.

Market basket analysis (MBA) output is a table of rules, each row showing antecedent (the items in the 'if' part of the rule), consequent (the items in the 'then' part), support, confidence, and lift. A typical rule might read: 'antecedent: bread, butter; consequent: jam; support: 0.04; confidence: 0.65; lift: 8.2'. This means 4 per cent of transactions contain bread, butter, and jam together; among transactions with bread and butter, 65 per cent also contain jam; the lift of 8.2 means the bread-and-butter combination is 8.2 times more likely to contain jam than a random transaction. Rules with lift greater than 2 are usually the actionable ones.

Real-time means three different things in practice, and the distinction matters. True real-time means data flowing continuously with latencies measured in milliseconds to seconds. Near real-time means data flowing in micro-batches with latencies measured in seconds to minutes. Operational reporting often described as real-time means refresh cycles of minutes to hours. The right answer depends on what the business needs. True real-time is appropriate for operational systems, fraud detection, and IoT. Near real-time covers most operational dashboards. Anything an hour or longer is batch, regardless of what the requirements document calls it.

Replayability is the ability to run a pipeline again from the original raw data and land at the same, or a deliberately improved, result. It depends on Bronze staying untouched and on transformation logic living in version-controlled notebooks or Dataflows rather than being applied once by hand. When a quality rule is added or a bug is fixed, a replayable pipeline can reprocess the full history through the new logic in one run, rather than patching only the records someone happened to notice were wrong.

The Hopton Fabric architecture is Bronze, Silver, Gold layers in OneLake. Bronze captures raw data from source systems unchanged. Silver cleans, structures, and standardises. Gold contains certified business-ready facts and dimensions. Power BI semantic models point at Gold using Direct Lake. Reports are built on the semantic models and inherit certified definitions. The architecture is the same we use across implementations regardless of source system or sector. Specifics vary in the source extraction patterns and the Gold-layer model design; the structure is consistent.

The decision review for a Fabric vs Databricks choice covers workload analysis, team and skill assessment, estate review, scoring against the six dimensions in the comparison deck, and a written recommendation. The review is independent of any subsequent build. A meaningful share of reviews end with us recommending Databricks, and that is fine. Helping you choose well matters more than winning the build.

The decision review for a Fabric vs Snowflake choice covers workload analysis, team and skill assessment, estate review, weighted scoring against the six dimensions in the comparison deck, and a written recommendation. Output is a document you can take to anyone, including in-house or another partner. The review is independent of any subsequent build engagement. About half of decision reviews end with us not doing the build, and that is fine.

In a medallion architecture, Bronze contains raw data exactly as extracted from source systems. JSON files from APIs, CSV exports, database snapshots, change logs. The format preserves source structure even when awkward. Silver contains cleaned data with deduplication, standardisation, and quality rules applied. Customer records are unified, product codes are consistent, dates are normalised. Gold contains business-ready facts and dimensions with the modelling decisions made. Sales fact tables, customer dimensions, time-intelligence dates. Power BI semantic models consume from Gold; ML notebooks usually consume from Silver or Gold depending on the use case.

Fabric implementations go wrong in three patterns we see repeatedly. Inadequate Silver layer cleansing, where Bronze data flows too quickly into Gold without proper standardisation, producing reports that almost reconcile but not quite. Capacity over-provisioning at launch, where teams buy F32 'for headroom' and run at 18 per cent utilisation. And inadequate governance configuration, where Purview is set up but not operationally maintained, so the labels and access governance drift. Each is preventable. None is unique to Fabric, but Fabric implementations exhibit the patterns more visibly because the platform is more integrated than what came before.

A previous forecasting investment that did not deliver is a common situation. The honest assessment usually shows that the technical work was sound but the operational integration was missing, the accuracy expectations were unrealistic, or the trust framework was absent. Forecasts that nobody acts on are wasted regardless of how accurate they are. Forecasts that everyone acts on without understanding the limits produce operational mistakes. The relaunch usually focuses on the operational and trust workstreams rather than rebuilding the technical core. Several of our forecasting engagements have been recoveries of previously failed projects.

Azure Data Factory is used for moving and transforming data between systems. ADF orchestrates pipelines that extract data from source systems (ERPs, CRMs, databases, APIs, files), transform it as needed, and load it into target systems (data lakes, data warehouses, downstream applications). It is the data integration backbone for most mid-market Azure data implementations. The capability is comparable to enterprise data integration tools (Informatica, Fivetran, Airbyte) with the advantage of being native to Azure and integrated with the wider Microsoft ecosystem.

Azure Data Lake Storage Gen2 is object storage optimised for analytical workloads. It is the storage layer underneath traditional Azure data architectures (ADF plus Synapse plus Power BI). For new builds, OneLake within Fabric is usually the right choice instead, because it provides similar capability with cleaner integration to the rest of the analytical stack. ADLS Gen2 remains the right choice when you have specific tooling that integrates with it directly, when you need to share storage across non-Microsoft analytical tools, or when existing investments make migration impractical.

Azure Machine Learning is Microsoft's dedicated ML platform with full lifecycle support: data preparation, model training, deployment, monitoring, and MLOps. It supports Python, R, automated ML, custom code, and prebuilt cognitive services. For mid-market ML workloads, Fabric Data Science is usually sufficient and more cleanly integrated with the wider analytical estate. Azure ML is the better choice for very high-volume training, complex MLOps requirements, model serving patterns that need dedicated compute, or ML workloads that are part of a broader Azure-only architecture.

Azure OpenAI Service is direct API access to OpenAI's large language models (GPT-4, GPT-3.5, embeddings) hosted in Azure with enterprise-grade security and governance. Azure OpenAI is the path for custom AI applications outside the Copilot interaction pattern: bespoke generative AI features in your own applications, custom retrieval-augmented generation systems, advanced agent patterns. For typical mid-market use cases, Microsoft Copilot products usually cover the need without requiring direct Azure OpenAI integration. Azure OpenAI becomes the right choice for specific applications that need direct API access.

Synapse Analytics was Microsoft's previous-generation integrated analytics platform, combining data warehousing, big data, and BI. It is now in maintenance rather than active development; Microsoft Fabric is the strategic successor. Existing Synapse customers can continue to use it, but new investments should generally go into Fabric. The migration from Synapse to Fabric is well-documented and usually less work than the original Synapse build. For mid-market businesses on Synapse, the migration question is when, not if.

Azure for data and analytics is Microsoft's cloud platform of services for data integration, storage, processing, machine learning, and AI. The relevant services for mid-market data and analytics work include Azure Data Factory (data integration and orchestration), Azure SQL Database and Managed Instance (relational databases), Azure Storage and Data Lake Storage (object storage), Azure Synapse Analytics (legacy analytics platform, now in maintenance), Azure Machine Learning (the ML platform), Azure OpenAI Service (generative AI), and Microsoft Purview (governance). Microsoft Fabric is the newer integrated platform that brings several of these together; the underlying Azure services remain available and useful.

Data Activator is the Fabric capability that triggers actions when conditions are met in streaming data. The pattern: define a rule (when temperature exceeds 30 degrees, when stock level drops below 100 units, when an account shows churn signals), and Data Activator evaluates the rule continuously against incoming events and triggers the configured action (Teams notification, email, Power Automate flow, custom webhook). The capability moves Fabric from analytics to action: not just observing what is happening but doing something about it.

DataOps is the application of DevOps principles to data engineering: automation, version control, monitoring, fast feedback cycles. Yes, it is relevant for mid-market, scaled appropriately. A mid-market business does not need an enterprise DataOps platform with dozens of tools, but the underlying disciplines (version control, automated testing, deployment pipelines, observability) apply at any scale. The pattern that works is selective adoption: pick the practices that produce the most value for your team size and skip the ones that add overhead without proportional benefit.

Direct Lake is a Power BI query mode unique to Microsoft Fabric. It allows Power BI to query data directly from the OneLake delta parquet files without importing or caching the data, and without the latency of a live DirectQuery connection. The result is near-import-speed performance on data that is always current - removing the trade-off between performance and freshness.

Fabric Copilot Capacity (FCC) is a separate capability that lets you point all Copilot usage across the tenant to one centralised capacity for billing and management. Still requires F64 or higher because it is designed to be shared across many workspaces. Most mid-market clients do not need this until they are operating at scale. Useful when you have many distinct Power BI workspaces and want to centralise the Copilot cost rather than carry it on each capacity.

KQL is Kusto Query Language. The query language for eventhouses and the broader Kusto ecosystem (Azure Data Explorer, Azure Monitor, Azure Sentinel). KQL is designed for time-series and log analytics workloads. The syntax is pipeline-style (data flows through a series of operators) rather than nested-query SQL. The language is genuinely well-designed for its domain: queries that would be awkward in SQL are concise in KQL, and the performance on time-series data is excellent. Worth learning if you are doing serious work with eventhouses.

Microsoft Fabric is a unified, SaaS analytics platform that brings data integration, a lakehouse and warehouse, real-time intelligence, data science, and Power BI together on a single storage layer called OneLake, with Copilot and AI woven in. It replaces the assembled stack many teams run today — a separate integration tool, warehouse, lake, data-science environment and BI tool — and the integration glue between them, consolidating everything into one governed environment with one security model and one bill.

Microsoft Fabric is Microsoft's unified, SaaS data platform, launched in 2023. It consolidates what previously required five or more separate Azure services (Synapse Analytics, Data Factory, Power BI Premium, Purview, and more) into a single, integrated platform. Fabric covers data engineering, data warehousing, real-time intelligence, data science, and Power BI reporting - all governed through a single OneLake storage layer. Compared with a fragmented traditional stack built from separately licensed, separately managed tools, this consolidation matters in three practical ways: one copy of data in OneLake rather than duplicate copies scattered across a warehouse, a lake, and a BI tool; far less integration engineering to connect those tools together; and one consumption-based capacity and governance model instead of several overlapping licences to manage.

Microsoft Purview is Microsoft's data governance platform, covering sensitivity labels, data classification, lineage, glossary, and access governance. Purview integrates with Fabric, Azure data services, and Microsoft 365 to provide consistent governance across the data estate. For mid-market businesses building serious analytical platforms, Purview is the standard governance layer. The Data Governance FAQ in our library covers the governance methodology; Purview is the toolset that supports it.

Prophet (open-source from Facebook/Meta) is a forecasting library designed for business time-series with strong seasonality, holiday effects, and trend changes. It is more accessible than ARIMA (less parameter tuning) and handles common business patterns out of the box. Prophet is particularly well-suited to retail and consumer goods forecasting where weekly and yearly seasonality dominate. The technique is a strong default for mid-market demand forecasting because it produces reasonable results without expert tuning.

Real-Time Intelligence in Microsoft Fabric is the Fabric workload for streaming and event-driven analytics. It includes eventstreams (for ingesting streaming data), eventhouses (for storing time-series and event data), KQL queryset (for querying the data), and Data Activator (for triggering actions based on events). The workload is built on Microsoft's Azure Data Explorer (Kusto) technology, mature and battle-tested at hyperscale within Microsoft's own services. Real-Time Intelligence is one of the six core Fabric workloads alongside Data Factory, Data Engineering, Data Warehouse, Data Science, and Power BI.

A data pipeline SLA is a documented commitment about the data a pipeline delivers, not just whether the servers were running. A good one covers freshness (how recent the data must be), availability (how often it is expected to be delivered on time), completeness (which sources and records must be present), the alerting that fires when a target is missed, and the incident-response expectation — who responds and how quickly. We tier SLAs by reporting criticality, so board and finance data carries a far tighter commitment than exploratory datasets.

A good false positive rate depends on the use case and the cost of investigation. For high-stakes anomalies (potential fraud, equipment failure), a false positive rate of 10 to 20 per cent is acceptable because the cost of missing a true anomaly is high. For lower-stakes anomalies (routine outliers in finance review), false positive rates need to be much lower (5 per cent or below) or the operational team stops engaging. The right threshold is tuned to balance the false positive rate against the missed-anomaly rate, with the balance set by the business impact of each.

A medallion architecture organises data into three progressively refined layers inside OneLake. Bronze holds an unaltered copy of what arrived from the source system. Silver holds that data once it has been validated, deduplicated and modelled at a usable grain. Gold holds business-ready, curated datasets built specifically for reporting and analytics. Each layer has a distinct job, so a problem at one stage rarely means rebuilding the whole pipeline.

A modern data architecture is a data platform built around three principles: separation of storage from compute (lakehouse architecture), separation of raw data from business-ready data (medallion architecture), and separation of code from configuration (deployment pipelines and version control). The result is a platform that scales with the business, supports multiple analytical workloads from the same data, and remains maintainable as the team and the data grow. The architecture is the difference between a collection of pipelines that work today and a platform that keeps working in five years.

An eventhouse is a streaming-optimised database in Fabric, built on the Kusto engine. It stores time-series and event data with sub-second query latency on billions of rows. The schema-on-read model handles semi-structured data well (JSON events, IoT telemetry, application logs) without requiring pre-defined schemas. Eventhouses are the right destination for high-volume streaming data; lakehouse Delta tables are the right destination for streaming data that needs to be combined with batch data for unified analytics. Most real-time implementations use both, with eventstreams routing events to each based on the use case.

An eventstream is the ingestion mechanism for streaming data into Fabric. Sources include Azure Event Hubs, IoT Hub, Kafka, custom REST endpoints, and Microsoft 365 audit logs. The eventstream routes events to destinations: into an eventhouse for time-series queries, into a lakehouse Delta table for combined batch and streaming analytics, or into a custom endpoint for application integration. The eventstream handles the streaming pipeline mechanics so the engineering team can focus on the analytical logic rather than the plumbing.

Anomaly detection is a pattern recognition technique that identifies observations differing significantly from expected behaviour. The output is typically a flag (anomaly or not) or a score (how unusual the observation is) per record or per time period. Anomaly detection is one of the most useful and underused ML techniques in mid-market analytics.

CDC is the discipline of capturing changes (inserts, updates, deletes) from source systems incrementally rather than re-reading the full source on every refresh. It matters for two reasons: efficiency (full reloads of large tables are expensive and slow) and fidelity (CDC captures the history of changes, enabling slowly changing dimensions and audit trails). Modern data platforms run on CDC for any source where it is available. Sources without CDC support are accommodated through other patterns, but CDC is the default for transactional systems.

Demand forecasting is a predictive technique that estimates future demand for products, SKUs, or services over a defined horizon. The output is typically a time-series of expected demand by item per period (week, month, quarter), with confidence intervals quantifying the uncertainty. Demand forecasting drives stock planning, production scheduling, capacity decisions, and supplier ordering. It is one of the highest-value ML use cases for product-led businesses because the cost of being wrong (stock-outs or over-stock) is usually material.

Isolation Forest is an ML technique that identifies anomalies based on how easily a record can be 'isolated' from the rest through random splits. Anomalous records are easier to isolate (fewer splits needed) than normal records. The technique handles multivariate data well, runs efficiently on large datasets, and produces interpretable scores. It is one of the standard go-to ML techniques for general-purpose anomaly detection.

Market basket analysis is a pattern-finding technique that identifies which products tend to be bought together. The output is a set of association rules of the form 'customers who buy A also buy B', each with three statistical measures: support (how often the combination appears), confidence (how often B is bought when A is), and lift (how much more likely B is bought when A is present, versus the baseline rate). MBA has been used in retail since the 1990s and remains one of the most reliable techniques for cross-sell, range planning, and store layout decisions.

Medallion architecture is a data organisation pattern with three layers: Bronze (raw data ingested from source systems, unchanged), Silver (cleaned, deduplicated, conformed data ready for analytical use), and Gold (business-ready data with the modelling, aggregations, and semantic structure for reporting and analytics). Each layer has a defined purpose, defined ownership, and defined consumption patterns. The pattern was popularised by Databricks but applies equally to Microsoft Fabric implementations.

Lambda architecture is the historical pattern of running parallel batch and streaming pipelines, with a serving layer combining the two. It was developed when batch and streaming systems were genuinely separate. Modern unified platforms (Fabric, Databricks, Snowflake) reduce the need for explicit Lambda architecture because the same storage layer can be queried by both batch and streaming workloads. Most new mid-market real-time implementations use a unified pattern rather than explicit Lambda. The principle of supporting both batch and streaming remains; the implementation has simplified.

The cost of switching BI platforms later is lower than it used to be, because both platforms support open table formats (Delta, Iceberg) and standard SQL, which makes switching easier than it once was. Switching is still meaningful work, mostly in semantic models, BI tooling and security. Plan as if you are choosing for five years. Switching is possible but not free, and choosing well now is cheaper than fixing it later.

Bronze is the ingestion layer: an immutable, as-is copy of source data, kept exactly as it arrived so nothing is lost or reinterpreted too early. Silver is the validation layer: records are deduplicated, conformed to agreed types and keys, checked against quality rules, and modelled at a clear grain. Gold is the consumption layer: business logic, aggregations and denormalisation are applied so the data is shaped for a specific report, semantic model or downstream application. Responsibility moves from preserving truth, to cleaning it, to presenting it.

The famous beer and nappies example is an often-cited story (whose details vary) about a US retailer discovering through MBA that beer and nappies were frequently bought together, allegedly because young fathers picking up nappies also picked up beer for the weekend. The story has acquired apocryphal status; the original analysis is debated. The example illustrates the principle: MBA surfaces non-obvious associations that the buying team would not have found through intuition alone. Whether or not the original story is fully accurate, the technique genuinely produces unexpected, actionable rules across most categories.

Power BI Copilot and Fabric Copilot both run on Fabric capacity. Since April 2025 the minimum capacity is F2 (around £200 per month). Before that change, the minimum was F64. The reduction is significant for mid-market organisations that were previously priced out. The capacity covers all Fabric workloads, not just Copilot, so the cost should be assessed against the whole platform value, not Copilot in isolation.

The medallion (bronze, silver, gold) architecture is a way of organising a data platform into three layers, each with one job. Bronze is raw, immutable landing that preserves data exactly as it arrived along with its ingestion metadata, which makes reprocessing possible. Silver is cleaned and validated — deduplicated, schema-standardised, quality-checked. Gold is business-modelled and analytics-ready, feeding semantic models and reports. Because each layer has a clear responsibility, you get end-to-end lineage, auditability and the ability to replay history from source.

ADF can handle most common mid-market sources. SaaS applications (Salesforce, Dynamics, ServiceNow, Workday) through native connectors. Databases (SQL Server, Oracle, MySQL, PostgreSQL) through database connectors. Files (CSV, JSON, Parquet) on cloud storage or on-premises. APIs through REST connectors. SAP through dedicated connectors. The connector library is broad and growing. For the rare source where no native connector exists, custom integration is achievable through Azure Functions or Logic Apps. Source system access is rarely the constraint.

Microsoft Fabric anomaly detection can monitor operations and supply-chain problems including: equipment performance monitoring (deviations from historical patterns indicating maintenance need), supplier delivery performance (lead time anomalies indicating disruption), warehouse productivity (unusual processing times), order pattern monitoring (demand anomalies in advance of stock-out risk), and customer service quality (response time or satisfaction anomalies). Each surfaces an issue while it is recoverable. The supply chain use cases tend to be the highest-value for mid-market because of the cost of stockouts and supplier failures.

Three orchestration patterns keep Azure and Fabric pipelines reliable as they scale: beyond the basic bronze, silver and gold layering, three patterns do most of the work. Parameterised pipelines: one pipeline definition with source, destination and load type passed in as parameters, rather than a hand-built pipeline per table or source system, which is what lets a platform scale past a handful of sources without becoming unmaintainable. Incremental loading: pipelines track a watermark, typically a last-modified timestamp or change-tracking column, so a scheduled run pulls only what changed rather than reprocessing an entire source every time, which is both faster and less likely to strain the source system it is reading from. Control flow with defined recovery: activities are chained with explicit success, failure and completion paths, so a failure partway through a load triggers a specific response, retry, alert, or skip-and-continue, instead of leaving bronze, silver and gold out of sync with each other silently. We also deploy pipeline changes through a proper release process, so a change tested in a development workspace is promoted to production deliberately rather than edited live, and every run is logged centrally so a failure is visible within minutes rather than discovered when someone notices a stale dashboard.

Three principles work best for pipeline design. Idempotency: a pipeline should produce the same result whether it runs once or many times, so reruns after failures are safe. Modularity: pipelines should be small and focused, composable into larger workflows rather than monolithic. Observability: pipelines should emit structured logs, metrics, and lineage information so failures can be diagnosed quickly. These principles produce data platforms that operate reliably with minimal intervention; absence of any one of them produces platforms that consume engineering time disproportionate to the value they deliver.

Three patterns of rules should be ignored, or at least treated with scepticism. Trivially obvious rules (peanut butter and jam, salt and pepper) confirm common knowledge without adding insight. Rules driven by single events or promotional periods rather than recurring patterns. Rules involving very low-frequency items where the support is too low to be statistically reliable. Filtering these out concentrates attention on the rules that genuinely surface non-obvious patterns. Most useful MBA outputs require some manual review by someone who understands the business context.

Demand forecasting uses techniques from three main categories. Classical time-series models (ARIMA, exponential smoothing, ETS) which extrapolate from historical patterns. Machine learning models (gradient-boosted regression, random forests, neural networks) which can incorporate features beyond the time-series. Hybrid and modern approaches (Prophet, DeepAR, Temporal Fusion Transformer) which combine elements of both. Each has its place. The right choice depends on data volume, the complexity of the demand patterns, and the team's analytical capability.

Transformation typically happens through Dataflows Gen2, for lower-code, business-owned logic, or notebooks running Spark for more complex engineering work. Data Factory pipelines orchestrate the sequence, triggering Bronze ingestion, then Silver validation and cleansing, then Gold aggregation, on a schedule or an event trigger. Everything lands as Delta tables in OneLake, and it is the Gold layer that a certified semantic model reads from directly using Direct Lake mode in Power BI, without duplicating the data again.

ML methods are worth the additional complexity in three patterns. Multivariate anomalies where unusualness depends on combinations of features (a customer's transaction is anomalous in this geographic location at this time even if neither factor alone is unusual). Highly seasonal data with complex patterns that simple statistical methods cannot capture. Use cases where the cost of false positives is high enough to justify the better precision of ML methods.

Gradient-boosted models are the right choice when the forecast benefits from features beyond the time-series itself: pricing, promotions, weather, competitor activity, marketing spend, listing changes. Gradient-boosted regression (LightGBM, XGBoost) or its variants can incorporate dozens of features per SKU per period and learn the relationships. The technique outperforms classical time-series when the data and features support it. The complexity is real: feature engineering and model tuning are substantial work, and the output is less interpretable than classical models.

Statistical methods are sufficient for univariate or low-dimensional data with clear distributions. Daily revenue, weekly transaction counts, response times. The statistical methods (X-bar charts, EWMA, Z-score thresholds, median absolute deviation) handle these cases well, are interpretable to non-technical stakeholders, and run with minimal computational cost. For most operational monitoring use cases, statistical methods are sufficient and the additional cost of ML methods is not justified.

Real-time analytics pays back in five recurring patterns. Operational dashboards where the value of acting in seconds exceeds the cost of the streaming infrastructure. Fraud detection where the window to prevent loss is short. Supply chain visibility where shortages or delays need to surface before they affect customers. IoT and connected products where the device data is inherently streaming. Customer-facing operations (call centres, dispatch, warehouse) where decisions are made in real time anyway. Outside these patterns, batch analytics is usually sufficient and significantly cheaper.

ARIMA is still the right choice for relatively stable products with regular demand patterns and a single primary driver (time and seasonality). ARIMA is well-understood, statistically defensible, and fast to fit. The output is interpretable. For mature products with several years of stable history and no major external influences, ARIMA produces accurate forecasts at low computational cost. The technique is venerable but not obsolete; it remains the right answer for a meaningful subset of forecasting use cases.

Databricks is clearly the right answer when ML is the centre of gravity, your team is code-first, and you have a multi-cloud reality. Notebook-native development, mature MLOps tooling, and platform-neutrality across clouds are real advantages. If your engineering team would rather write Python than open a designer, Databricks fits how they actually work. Fabric will feel constraining.

Fabric is clearly the right answer when BI is the centre of gravity, your organisation is on M365, and your team is small or mixed-skill. The integrated experience reduces the surface area to learn and run. Fabric is also the lower-effort answer when you are already on Power BI Premium, because the licence path flows directly into Fabric capacity. For most UK mid-market businesses we work with, this describes them, and Fabric is the lower-effort answer.

Snowflake is clearly the right answer in three scenarios. Multi-cloud or AWS-first estates, because Fabric is Azure only. Heavy data engineering teams who prefer SQL-first, code-led tooling. And spiky, unpredictable query workloads, where Snowflake's per-query consumption model fits better than Fabric's fixed capacity. If any of these describe you, Snowflake is the better starting point.

Type 1 for attributes that should always reflect current state (descriptive labels, internal categorisations that get refined). Type 2 for attributes where historical context matters (geographic territory, sales rep assignment, customer tier, product hierarchy). The decision should be deliberate per attribute, not a blanket policy. Most dimensions are mixed: some attributes Type 1, some attributes Type 2. The Silver layer is where the SCD logic lives in our standard architecture.

Microsoft Learn has a free KQL learning path that covers the language well in a few hours. The Microsoft documentation for Kusto is comprehensive. Several books (most notably 'Mastering KQL' and 'Kusto Query Language Pocket Reference') cover the language in more depth. For mid-market teams adopting Real-Time Intelligence, the standard pattern is one or two team members learning KQL deeply and the rest of the team picking it up by example. The learning curve is moderate; the productivity gain is meaningful for streaming workloads.

The full comparison deck is on hoptonanalytics.com under Resources. The deck covers the six dimensions that decide it, the common myths and pitfalls, six clear scenarios for picking each platform, and two real worked examples. To discuss a specific situation, email hello@hoptonanalytics.com.

Cosmos DB is Azure's distributed NoSQL database, suited to specific use cases: massive scale, global distribution, flexible schema, document or graph workloads. For typical mid-market data and analytics work, Cosmos DB is rarely the right choice; the use cases that justify it are uncommon at mid-market scale and the cost can rise quickly without careful design. Mid-market businesses occasionally use Cosmos DB for specific application backends (mobile apps, IoT scenarios) but rarely as the analytical data store.

Market basket analysis pays back in five common applications. Cross-sell recommendations (when a customer puts A in the basket, suggest B). Email campaign segmentation (target customers who have bought A but not B). Store layout decisions (place strongly associated products near each other or deliberately apart). Range planning (identify products that anchor baskets versus products that come along). Promotional design (price the anchor product to drive baskets). Each pays back when the marginal margin from the rule-driven action exceeds the cost of implementing the rule. For most retailers and wholesalers, several of the rules surfaced are commercially material.

Anomaly detection pays back fastest in five recurring patterns. Finance integrity (unusual journals, expense outliers, supplier payment anomalies). Operations monitoring (equipment, process, service quality). Supply chain (delivery exceptions, demand spikes, stock anomalies). Customer behaviour (unusual purchase patterns, account compromise). Cyber security (unusual access patterns, data exfiltration).

Demand forecasting pays back fastest in five business shapes. Retailers with significant stock investment where over-stock and stock-out costs are material. FMCG and consumer goods with multi-channel distribution. Wholesalers and distributors with thousands of SKUs and multi-warehouse stock. Manufacturers with long production lead times. Subscription businesses needing capacity planning. The pay-back is typically through stock optimisation savings (lower stock levels at the same service level, or higher service levels at the same stock level) and through fewer stock-outs reaching customers.

For anomaly detection, use Scikit-learn for isolation forest, one-class SVM, and basic statistical methods. PyOD (Python Outlier Detection) for a wider range of algorithms including local outlier factor, autoencoders, and ensemble methods. Statsmodels for control charts and time-series anomaly detection. Prophet's anomaly detection capability for seasonal time-series. Microsoft Azure Anomaly Detector (a cognitive service) for use cases where the prebuilt service is the right answer. The choice of library depends on the specific technique; the standard data science stack covers the breadth.

For demand forecasting, use Prophet for the default implementation. Statsmodels for ARIMA and classical time-series. LightGBM or XGBoost for gradient-boosted regression. Sktime for unified time-series API across techniques. The lifetimes ecosystem (lifelines for survival analysis, lifetimes for CLV) is adjacent rather than directly used in forecasting. The standard data science stack covers demand forecasting end to end. We have notebook templates for each technique that we adapt to specific client engagements.

The two standard algorithms are Apriori and FP-Growth, both available through Python libraries. Apriori is the classic algorithm: simple, well-understood, slower on large datasets. FP-Growth is the more modern algorithm: faster, especially on large transaction volumes, with similar output. For mid-market data volumes either works; for very large datasets FP-Growth is meaningfully faster. The choice is mostly a performance one. The output is the same: a set of association rules with support, confidence, and lift.

Which platform is cheaper overall is highly situation-specific. Both can be cheaper. Fabric tends to be cheaper for steady BI-led workloads on M365 because Power BI licences flow in and capacity is predictable. Snowflake tends to be cheaper for spiky workloads where compute can scale to zero. The total cost picture also includes integration cost, training and team operability, and those often outweigh raw platform cost.

Which platform is cheaper is highly situation-specific. Fabric tends to be cheaper for steady, BI-led workloads on M365 because Power BI licences flow into Fabric capacity. Databricks tends to be cheaper for spiky compute workloads where serverless SQL can scale to zero between queries. The total cost picture also includes integration and team operability, which often outweigh raw platform cost.

Most modern transactional databases support CDC. SQL Server (with Change Tracking or CDC features), PostgreSQL (logical replication), MySQL (binlog-based replication), Oracle (LogMiner or GoldenGate), Microsoft Dynamics 365 (Dataverse change tracking), and most cloud data sources expose change streams. SaaS applications increasingly expose webhooks or change feeds. The patterns vary; the principle is universal. Sources without native CDC can be approximated through delta loads (extract only records changed since last run) or full snapshots compared period to period.

In a well-run Fabric estate, only the ingestion pipelines themselves write to Bronze, never analysts or ad hoc scripts editing files directly. Restricting write access to the automated pipeline is what keeps the layer trustworthy as a permanent record, and it's usually enforced through workspace roles and OneLake access policies rather than convention alone.

Microsoft Fabric matters for modern data architecture because Fabric implements the modern architecture as a productised platform rather than as components to assemble. OneLake provides the unified storage. The Lakehouse and Warehouse workloads provide the analytical compute. Fabric Data Factory provides the orchestration. Microsoft Purview provides the governance. The integration is what differentiates Fabric from assembling these capabilities from raw Azure components. For most mid-market businesses, Fabric is the right modern data architecture platform; for enterprises with very specific needs, raw Azure or hybrid approaches still have a place.

Version control matters for data engineering because data pipelines are code, and code without version control is a liability. Version control provides three capabilities every serious data platform needs: history of changes (who changed what and when), branching for parallel work and review, and reproducibility (the ability to roll back to a previous working state). Without version control, data engineering teams accumulate technical debt invisibly and lose the ability to recover from mistakes. The Microsoft Fabric Git integration brings version control to the platform natively.

You can trust our Fabric vs Databricks comparison, even though we are a Microsoft consultancy, because the work that fails costs us more than the work we do not win. A misplaced Fabric recommendation that fails in production damages our reputation and our renewal pipeline far more than a clean Databricks recommendation costs us in this one project. We can show specific situations where we recommended Databricks and explain why.

You can trust our Fabric vs Snowflake comparison, even though we are a Microsoft consultancy, for two reasons. We do not benefit from selling you the wrong platform. A failed Fabric project costs us reputation and renewal far more than a clean Snowflake recommendation costs us in lost revenue. And we have actively recommended Snowflake to clients where it was the right answer, including to clients who came to us assuming Fabric was the inevitable choice. The recommendations and the rationale are documented and we are happy to walk through them.

Hopton is a strong fit for Fabric implementations for three reasons. We are a Microsoft data and analytics specialist; Fabric is in the centre of our work, not a side capability. We have delivered Fabric implementations across mid-market sectors (retail, construction, FMCG, healthcare, professional services, recruitment) so the architectural patterns are well-established. We hold the Microsoft accreditations relevant to Fabric work and the team holds individual certifications including the DP-600 (Fabric Analytics Engineer) and DP-700 (Fabric Data Engineer). The work is in the centre of what we do, not at the edge.

A medallion architecture uses three layers rather than two or four because the three layers correspond to three distinct concerns. Bronze is about capture (getting data in reliably without losing fidelity). Silver is about quality (making the data trustworthy without yet imposing business semantics). Gold is about meaning (encoding business rules and structure for the consumption layer). Two layers conflate quality and meaning into one stage, which produces brittle pipelines that need rebuilding when business rules change. Four layers add an intermediate stage that rarely earns its place at mid-market scale. Three is the right balance.

Yes — Hopton will recommend against real-time when batch is sufficient. Real-time is one of the technologies most often over-specified in scoping conversations because it sounds modern. Our discovery work usually surfaces whether the requirements genuinely need real-time or whether near-real-time batch would deliver the value at much lower cost. We have written scoping reports recommending against real-time investment; the recommendation costs us a more complex engagement and earns trust for the simpler one we deliver instead.

There are three hidden costs to plan for. First, the data layer rebuild, which is often larger than expected because QVDs hide complexity. Second, user retraining, which is more than a one-hour session for power users. Third, parallel running for two to three months while users transition. None of these is hidden if you plan for them. They are hidden if you assume Power BI is just a swap for Qlik.

Yes — there are situations where staying on Tableau is the right call. Organisations with deep, specialist analyst teams doing highly bespoke visual analytics, particularly those without a significant existing Microsoft 365 or Azure footprint, may find the switching cost and retraining effort outweighs the licensing saving. We would say so directly rather than push a migration that does not make sense for a specific client.

Cognos and Power BI can run in parallel during the transition, and we recommend it for exactly the same reason as any other BI migration: running both platforms in parallel for at least one reporting cycle and reconciling figures before retiring Cognos access for a given report, so no one loses a working report mid-transition.

Cognos reports and packages cannot be automatically converted reliably. Cognos Framework Manager packages and report specifications use fundamentally different modelling concepts to Power BI's semantic model, and automated conversion tools tend to produce something technically functional but poorly structured and hard to maintain going forward. We rebuild the underlying model deliberately rather than attempting automated conversion.

Hopton can help even if your spreadsheets pull data from several different systems already; this is in fact the more common case than a single-source spreadsheet, and it is exactly the kind of multi-system reconciliation work a proper semantic model is designed to solve better than a spreadsheet held together with manual copy-paste and VLOOKUPs.

Yes — Hopton can migrate from Looker to Power BI. Once the strategic decision to move has been made, Hopton runs it as a structured engagement: auditing the existing Looker dashboards and LookML models, rebuilding the semantic model natively in Power BI, recreating the report visuals, and running a short parallel-validation period before cutover. LookML does not convert automatically, so the architectural rebuild is the bulk of the work; the visual rebuild is comparatively quick. We use the same phased approach for the Tableau and Qlik migrations covered elsewhere in this FAQ library.

Tableau workbooks cannot be automatically converted to Power BI reports reliably, despite some third-party tools claiming to do this. Tableau and Power BI have fundamentally different underlying data models and calculation languages, and an automated conversion tends to produce something that opens in Power BI but is poorly structured, hard to maintain, and does not reflect Power BI best practice. We rebuild rather than attempt automated conversion.

Yes — modernisation can work alongside a future replacement, and in many cases it should. The modernised analytics layer is independent of the source system. If a replacement happens later, the analytics layer is rebuilt to point at the new source. The historical data accumulated in the modernised layer survives the replacement, which is the opposite of the usual pattern. This decouples the analytics conversation from the system conversation. They become separate projects rather than one combined risk.

You can sometimes keep using historical data after a replacement, with effort. Most replacement projects bring across enough recent history for operational continuity but cut older data for cost or schema reasons. Reuniting the old and new history afterwards is a separate project that often does not happen. The honest position is that replacement makes historical data harder to use, not easier. Modernisation preserves the history because it does not touch the source system. The history continues to accumulate in the existing place and the analytics layer pulls from it.

Report by report is almost always better. Group related reports into batches, migrate each batch, get user sign-off, then move to the next. Big-bang switches are higher risk and higher stress. The exception is when the underlying data layer needs a complete rebuild, in which case the data layer migration must complete before any reports go live. Even then, the report layer is incremental.

Yes - Fabric capacities can be paused when not in use and resized more flexibly than Premium capacities typically were, which is one of the more concrete cost-management advantages of the move, particularly for capacities that see uneven usage across the week or year.

Yes — you can run Qlik and Power BI in parallel during the transition, and you almost certainly will. Two to three months of parallel running lets users transition gradually and gives you a fallback if a Power BI report has an issue. Plan for the cost. The risk is letting parallel running drift on indefinitely. A fixed switch-off date avoids that.

You can run SSRS and Power BI in parallel during the migration, and almost always should for at least four to eight weeks. SSRS subscriptions in particular need to keep delivering while Power BI equivalents bed in. Set a fixed switch-off date in the audit phase. SSRS instances often live for years after they should have died if there is no commitment to a date.

Yes — you can run Tableau and Power BI side by side during a transition, and we recommend it. We run both platforms in parallel for at least one full reporting cycle, reconciling figures between the two, before retiring Tableau access for a given report, so no one is left without a working report during the transition.

RDL files mostly convert to Power BI Paginated automatically, with care. The Power BI Report Builder accepts RDL files and most simple RDL files convert with minimal changes. The trouble starts with embedded VB.NET code, custom assemblies, subreports and complex datasets. Each needs separate handling. Allow time for testing rather than assuming the conversion is one-click.

No, user-level licensing (Power BI Pro or Premium Per User) is separate from capacity licensing and is unaffected by a Premium-to-Fabric capacity migration. This migration specifically concerns the shared capacity that hosts your workspaces, not individual user licences.

Your Tableau dashboards do not necessarily need to look identical in Power BI, and we would not usually recommend it. We aim to preserve the metrics, structure, and interactivity users rely on, while taking the opportunity to apply good Power BI-specific design practice rather than forcing a visual layout that fought against Tableau's conventions to now fight against Power BI's.

You can license Power BI-only usage through Fabric F SKUs without adopting the other Fabric workloads at all - a Fabric capacity licenses Power BI Premium features whether or not you use Fabric's data engineering, warehouse, or real-time capabilities. The migration is a licensing and platform change more than an immediate requirement to adopt the wider Fabric feature set.

Ad hoc flexibility in the exact way Excel offers it does reduce for the governed, shared reports - that is largely the point, since uncontrolled ad hoc changes are what created the version-control problem in the first place. Power BI's own self-service features (Analyze in Excel, Power BI Desktop for individual analysis, DAX for new measures) provide a different, more controlled kind of flexibility on top of the trusted model.

Power BI alone is sufficient for the great majority of spreadsheet migrations. Fabric becomes relevant where the underlying data volumes are large, where multiple messy source systems need proper data engineering before they can feed a semantic model reliably, or where the ambition extends well beyond replacing the spreadsheet into a wider data platform.

Whether you need to migrate the data warehouse as well as the reporting layer depends on where your data currently sits. If Cognos reports query a well-structured existing data warehouse, that warehouse can often remain as the Power BI data source with limited change. If Cognos itself has been doing significant data preparation work, that logic typically needs to move into Power Query or a Microsoft Fabric pipeline as part of the migration.

Yes — we often do BC reporting migrations as part of SSRS work. Many SSRS reports built for older Microsoft ERPs (NAV, AX, GP) need careful handling because they touch BC equivalents. We have a separate playbook for BC reporting options, and the SSRS migration sometimes sits inside that wider conversation. If you are running BC and SSRS together, the two playbooks complement each other.

We deliver both Power BI on Fabric and Power BI Premium without Fabric. If your destination is Power BI Premium without Fabric, that is a valid and supported path. The decision depends on your data volumes, your wider Microsoft estate, and your appetite for sitting on the modern stack. The audit covers this question explicitly: not every Qlik migration ends with Fabric, and we will tell you when it does not need to.

Hopton has specific experience migrating clients off Tableau, alongside our broader experience migrating clients from Qlik, SSRS, and Excel-based reporting onto Power BI. The underlying discipline - understanding existing logic thoroughly before rebuilding it properly rather than translating it mechanically - is consistent across all of these migration types.

Hopton has specific experience with Cognos migrations, as part of our broader legacy BI migration practice alongside Qlik, Tableau, SSRS, and Excel-based reporting migrations. The core discipline - understanding existing logic thoroughly before rebuilding it properly in Power BI - is the same regardless of which legacy platform is being replaced.

Yes - the capacity sizing and cost analysis is usually the more valuable part of this engagement, since the technical reassignment itself is comparatively quick. We review your current Premium capacity utilisation, model the appropriate Fabric SKU size, and give you a clear cost comparison before any switch happens.

We do not implement or support Tableau as an ongoing platform. Our specialism is the Microsoft data and analytics stack, and our Tableau-related work is specifically migration onto Power BI, not ongoing Tableau delivery.

Hopton only migrates clients off Cognos onto Power BI, rather than implementing or supporting Cognos. Our specialism is the Microsoft data and analytics stack, and our Cognos-related work is specifically about moving clients from it, not delivering or supporting Cognos as an ongoing platform.

This kind of migration is one of the most common starting points for new Hopton engagements. A large proportion of mid-market businesses we work with are moving off Excel-based reporting as their first step into a proper Power BI estate, so this is core, well-practised work rather than a peripheral service.

Both Tableau and Power BI have invested heavily in AI and natural-language querying - Tableau through Tableau Pulse and Einstein-related capability under Salesforce ownership, Power BI through Copilot for Power BI. For most mid-market organisations already committed to the Microsoft ecosystem, Power BI Copilot benefits from deeper integration with the Microsoft 365 tools those users already work in daily.

Migrating from Tableau makes sense if you are happy with it technically but not with the cost - this is one of the more common and rational reasons to migrate. Cost consolidation on its own is a legitimate business case, provided the migration itself is planned carefully enough that the switching cost does not erode the savings in year one.

No — moving from Cognos to Power BI does not mean losing centralised governance, provided the migration is done properly. Power BI supports strong centralised governance through certified semantic models, workspace permissions, and row-level security; it simply also allows self-service report building on top of that governed layer, which Cognos's more centralised model does not emphasise as strongly.

No — moving to Power BI does not mean giving up Excel entirely, and we would not recommend that framing. Power BI becomes the governed reporting layer; Excel remains genuinely useful for ad hoc analysis, one-off modelling, and scenarios that do not need to be a permanent, shared report. Power BI has native Excel connectivity (Analyze in Excel) specifically so people can keep working in Excel against a trusted, governed dataset rather than a disconnected copy.

Yes — your Power BI Premium renewal date matters for planning this migration; it is usually the natural trigger point. Migrating around your existing renewal minimises the risk of running two capacities simultaneously and lets you align the new Fabric capacity commitment with your existing budgeting cycle.

No — your existing Power BI content does not need to be rebuilt to move to Fabric capacity. Existing datasets, reports, and dashboards continue to work once reassigned to a Fabric capacity; this is fundamentally a capacity and licensing change, not a content migration. Where it gets more involved is if you also want to take advantage of Fabric's other workloads, which is a separate decision from the capacity licensing move itself.

No — the assessment does not lock you into using Hopton for the build. The assessment is independent. The output is a written document you can take to anyone, including in-house teams or other consultancies. Several clients have used the assessment to inform a procurement process that we did not win. We are comfortable with that because the assessment work itself is valuable regardless of who does the build. Recommending the path that is right for the client, even if we do not deliver it, builds the trust that earns subsequent work.

Workspace reassignment is designed to be low-disruption, but we schedule it outside peak reporting hours and validate that refreshes, row-level security, and performance are behaving as expected immediately after the switch, rather than assuming a purely administrative change carries zero risk.

The source system does not have to support modern APIs; it helps but is not strictly required. Older systems can be extracted via direct database access, scheduled exports, or custom integration patterns. The work is more involved but it is not a blocker. We have modernised analytics layers on top of source systems older than thirty years. The technique adjusts. The outcome is the same: a modern analytics layer that delivers the visible value without touching the source system.

This applies to both QlikView and Qlik Sense. QlikView is end-of-life and the migration urgency is higher there. Qlik Sense is supported but the same drivers apply: licensing economics, feature parity with Power BI on the workloads most mid-market organisations actually run, and the integration tax of running an analytics platform separate from the rest of the Microsoft estate.

Layout and interactivity change, generally for the better - Power BI supports filtering, drill-down, and cross-report navigation that a static spreadsheet cannot. We aim to preserve the metrics and structure people already trust and are used to working with, while improving how they are presented and interacted with.

Cognos's namespace, group, and package-based security concepts map onto Power BI's workspace roles and row-level security model, but not one-to-one. We map your existing Cognos security requirements onto the nearest appropriate Power BI equivalent deliberately, rather than leaving this to default settings during migration.

To avoid losing your Qlik power users, involve them early, often, and on their own reports. Power users have spent years learning Qlik and they have legitimate concerns about whether Power BI will let them work the same way. The answer is sometimes yes, sometimes no, and being honest about both builds trust. Train them on Power BI using the reports they care about, not on a generic course.

Email hello@hoptonanalytics.com with a description of your current Tableau estate - roughly how many workbooks, how many active users, and which data sources are involved. The first conversation is free and exploratory, and typically leads to a scoped Establish phase producing a firm cost and timeline estimate.

Email hello@hoptonanalytics.com with a description of your current Cognos estate - roughly how many packages, reports, and active users are involved, and how long the environment has been in place. The first conversation is free and exploratory, and typically leads to a scoped Establish phase producing a firm estimate.

Email hello@hoptonanalytics.com with a short description of your current spreadsheet-based reporting and the specific pain points (version control, a single point of failure, manual effort, trust in the numbers). The first conversation is free and exploratory, and typically leads to a scoped Establish phase.

Email hello@hoptonanalytics.com with details of your current Premium capacity SKU and roughly how many workspaces and reports it hosts. We will review your utilisation, model the right Fabric capacity size, and give you a clear cost and migration plan before you commit to anything.

During a migration, we handle rarely-run reports that still matter by migrating them, but documenting what they are for. Annual audit reports, regulatory reports and similar may run twice a year and matter both times. Execution frequency alone is the wrong test. Combine it with named ownership and sensible judgement. The audit phase is where this gets sorted, not the build.

We know what size Fabric capacity we actually need by analysing your current Premium capacity's utilisation - CPU and memory consumption patterns, peak usage times, and how close to capacity limits you currently run - and mapping that onto the nearest appropriate F SKU, rather than assuming a like-for-like size match is automatically correct given the different underlying compute model.

Four things tell you when the SSRS migration is done. Every active report is live in Power BI as paginated or interactive. Every active subscription has a Power BI equivalent running. Inactive reports are documented and retired with sign-off. SSRS server is off and licences released. If any one is missing, the project is not done. The last one is where most migrations linger if no one drives the switch-off.

You know the migration is done when three things have happened. Every report on the active list is live in Power BI, owned, and signed off. Power users are productive in Power BI on their own work. Qlik servers are off, licences cancelled. If any one of those three is missing, the migration is not done. The third one is the one most projects skip if they are not careful.

Three quick tests tell you whether the problem is your source system or your reporting layer. First, does the source system have the data you need, however awkward to get to? If yes, the problem is the analytics layer. Second, are most of the complaints about reports, dashboards, and analyses, or about transactional behaviour? If reports, the problem is analytics. Third, what would change in the business if the same data appeared cleanly in a modern reporting layer? If the answer is 'a lot', you do not need a new core system. The Reporting Modernisation Assessment runs these tests properly.

Three signals, in order of strength, tell you which SSRS reports are actually being used. Active subscriptions, because someone deliberately set them up and presumably reads them. Recent execution logs from the SSRS database, which tell you when each report last ran and how often. Sign-off from named owners, because anonymous reports rarely have anyone willing to defend them. Combine all three and you have the active list.

We manage SSRS subscription transitions during a Power BI migration by mapping every active SSRS subscription, building the Power BI equivalent, running both for a few weeks, then switching off the SSRS one. Recipients see the Power BI version arriving on schedule before the SSRS version disappears. The trust this builds is worth the few weeks of duplicate emails. Switching cold creates anxiety and complaints.

We validate that performance is at least as good after moving to Fabric capacity by comparing report load times, refresh durations, and capacity utilisation metrics before and after the move for a representative sample of your most business-critical reports, rather than assuming a comparable SKU size automatically delivers comparable performance.

Cognos prompts and macros are generally replaced with Power BI's native filtering, slicers, and "what-if" parameters, which achieve similar interactive outcomes through different mechanisms. Some highly bespoke macro-driven logic needs custom DAX or Power Query work to reproduce properly rather than a direct equivalent.

We handle Tableau Server or Tableau Cloud governance and permissions when moving to Power BI by mapping existing Tableau permission structures (who can see and edit what) onto Power BI's workspace and row-level security model, which works differently under the hood but achieves equivalent governance outcomes. This mapping exercise is done deliberately rather than left to default settings, since the two platforms' security models are not a direct one-to-one match.

Embedded VB.NET and custom assemblies often hide business rules and need extracting carefully. Embedded code in SSRS reports tends to grow organically, with formatters, calculation helpers and IIF chains accumulating over years. Document the logic, decide whether it belongs in the data layer, the report, or somewhere else, then rebuild it. Migrating without this audit means rebuilding bugs into the new platform.

For stored procedures that drive SSRS reports, we audit them, document them, then decide what comes with you into the Power BI migration. Many SSRS estates have business logic buried in stored procedures that nobody fully understands. The migration is the moment to surface that logic. Some procs come across to the new architecture. Some get rewritten as DAX or Power Query. Some get retired with their reports. The decision is per proc, not blanket.

Subreports do not have a direct Power BI equivalent. Most need to be flattened into the parent report, replaced with drill-through pages, or split into separate paginated reports. The right answer depends on the use case. Plan extra time for any report with significant subreport use, particularly if subreports drive the page layout.

Subscriptions are usually the most-used SSRS feature and often the least documented. Active email subscriptions are the strongest signal of which reports are actually used. Map every active subscription before switching anything off. Power BI subscriptions cover the same use cases, sometimes more cleanly. The migration is the moment to also question whether each subscription still serves a purpose.

We migrate Tableau calculated fields into Power BI by understanding the business logic each calculated field represents and rebuilding it as a proper DAX measure in Power BI's semantic model, rather than translating formula syntax mechanically. This is also the opportunity to correct or simplify calculations that may have accumulated workarounds over the Tableau workbook's lifetime.

We migrate a Cognos Framework Manager model into Power BI by treating the Framework Manager model as a specification of the business's dimensional structure and calculation logic, then rebuilding that structure properly as a Power BI semantic model with appropriate relationships, hierarchies, and DAX measures, rather than translating metadata mechanically.

We migrate logic out of a complex, years-old spreadsheet by treating the spreadsheet as a specification to be understood and validated, not code to be copied. We work through the existing calculations with the people who use and, where possible, built the spreadsheet, documenting the actual business rules (including workarounds and exceptions) before rebuilding them properly as DAX measures and Power Query steps in Power BI.

We scope an Excel migration before committing to a full project through our standard Establish phase: reviewing your current spreadsheets, understanding the business logic and who depends on it, and agreeing a clear list of what "done" looks like before any rebuild work starts. This produces a written plan and cost estimate you can act on even if you decide not to proceed with the Build phase immediately.

We validate that the new Power BI report matches the old spreadsheet by running both in parallel for at least one full reporting cycle and reconciling every material figure line by line before the spreadsheet is retired. Differences get investigated individually - some will be genuine spreadsheet errors being corrected, and we make sure the client agrees with and understands every one of those before go-live.

Hopton engages on an SSRS migration in two ways. A migration audit, two to three weeks at fixed price, with no obligation to proceed. Or a full migration programme, direct contracting, fixed milestones, SSRS retirement date in the plan from day one. Most clients start with the audit because the audit answer often changes the migration scope significantly.

Hopton typically engages on a Qlik migration in two ways. A migration audit, which is a two to three week assessment of your Qlik estate at fixed price and fixed output, with no obligation to proceed. Or a full migration programme, end to end, with direct contracting and a decommission date written into the plan from day one. Most clients start with the audit because it is the cheapest insurance on a project of this size.

Qlik Set Analysis does not translate directly to DAX. Set expressions, dollar-sign expansions and complex modifiers do not have one-to-one DAX equivalents. Most Set Analysis logic gets rewritten as DAX measures, often more cleanly than the original. Treat Set Analysis as documentation of intent, not as code to be ported. Rewrite the intent in DAX patterns native to Power BI.

Section Access logic gets re-implemented as Row-Level Security in Power BI. The mechanism is different but the intent is usually the same. The harder part is that Section Access often hides business rules that nobody has written down. Surface those rules first, document them, get sign-off, then implement RLS to match. Skipping the documentation step causes most RLS bugs we see.

Synapse-to-Fabric migration works through a defined migration path that Microsoft has documented and tooled. Synapse Workspaces and Pipelines map to Fabric workspaces and Fabric Data Factory. Synapse Dedicated SQL Pools map to Fabric Data Warehouse. Synapse Spark Pools map to Fabric Data Engineering. The migration is incremental: components can be migrated one at a time as the right opportunities arise, rather than as a single forklift project.

A Fabric modernisation engagement progresses into a build phase after the readiness assessment: the build phase usually runs three to six months. We extract source data into Fabric, build certified semantic models, deliver the priority reports, and establish governance. The work is incremental: visible value within the first eight to twelve weeks, full delivery within six months. Continuity is the optional ongoing engagement that maintains and extends the modernised platform after launch.

Power BI is typically materially cheaper per user, particularly for organisations already paying for Microsoft 365, where Power BI often represents an incremental cost rather than an entirely new licence line. Tableau's licensing is usually higher per seat and priced independently of any other software you already own.

Cognos has traditionally centred on IT-authored, centrally governed reports and packages, with business users mainly consuming rather than building. Power BI leans further towards self-service, where trained business users build their own reports against a governed semantic model. Neither approach is objectively better; the right fit depends on how much you want reporting authorship distributed versus centralised in your organisation.

Paginated reports preserve print fidelity. Interactive Power BI reports do not, by design. If a report is printed, it should be paginated. Forcing interactive reports into print contexts is the most common cause of complaint after an SSRS migration. Get the per-report decision right at the audit phase and print fidelity is a non-issue.

A Cognos to Power BI migration typically takes, for a focused core reporting suite, eight to fourteen weeks from discovery through validated go-live, reflecting the typically more complex underlying data models found in longer-established Cognos estates. Larger, long-running Cognos deployments with many packages and report authors are usually phased over a longer programme.

A Tableau to Power BI migration typically takes six to twelve weeks for a focused set of core dashboards, from discovery through validated go-live. Larger Tableau estates with many interconnected workbooks and a broad analyst user base are usually phased over a longer programme, prioritising the highest-usage dashboards first.

Modernisation typically takes three to six months for a mid-market business with one main source system. Replacement takes 18 to 30 months. The cost ratio is comparable: modernisation is usually 10 to 25 per cent of the cost of a comparable replacement. The risk ratio is wider still, because modernisation projects have failure modes that are smaller and more recoverable than replacement projects. The only thing replacement does that modernisation cannot is fix problems that are genuinely in the source system.

A single, well-defined core reporting spreadsheet typically takes four to eight weeks from discovery through to validated go-live. Migrating an entire suite of interconnected spreadsheets across finance, sales, and operations is a larger programme, usually run in phases rather than as one migration.

A typical Qlik to Power BI migration takes three to six months for a typical mid-market estate of fifty to two hundred Qlik objects. Larger estates take longer, mostly because the audit phase is where the real work sits. The build phase is usually the most predictable part. The pre-build audit and the post-build user transition are where projects slip if they slip.

A typical SSRS migration takes two to six months, with a wide range driven by estate size more than by complexity per report. A small estate of fifty active reports finishes in two to three months. A two-hundred-report estate with stored proc dependencies and active subscriptions takes four to six. The audit phase often takes longer than expected because most SSRS estates have not been mapped in years.

Forty to sixty per cent on licence cost is typical for mid-market organisations already on M365. Power BI Pro is bundled with most plans. Premium Per User and Premium Capacity scale up from there. The exact saving depends on your current Qlik footprint and your M365 estate. The gap usually pays for the migration project inside the first eighteen months.

A Qlik to Power BI migration costs, for most mid-market migrations, between sixty and two hundred thousand pounds, depending on estate size and complexity. The audit is usually fifteen to twenty-five thousand. The build scales with the number of Qlik apps and the complexity of the data layer underneath. The user transition phase is often underestimated and can be ten to twenty per cent of total project cost.

Gartner data puts ERP project failure rates at 55 to 75 per cent. Panorama Consulting reports an average cost overrun of 189 per cent in 2025. McKinsey reports digital transformation failure rates above 70 per cent. The pattern is consistent across industry analysts and across decades. Migration is genuinely hard, more often than vendor narratives suggest. The likelihood of going significantly over budget, missing milestones, or delivering less than promised is higher than most boards assume going in.

Workspaces are typically split by function rather than left as one large shared space: a development workspace, a test workspace, and a production workspace at minimum, so a change can be validated before it reaches anything a business user sees, with promotion between them controlled rather than ad hoc. Within production, workspaces are usually split further by domain or department where access genuinely needs to differ, since a workspace is the unit that workspace roles apply to. On residency, Fabric capacity is provisioned in a specific Azure region, and that determines where the underlying data physically sits; for UK organisations this is normally a UK region for data residency and compliance reasons, and it is one of the decisions made explicitly during the discovery week of a migration, not left as a default. Getting workspace structure right before migrating matters more than it looks: restructuring workspaces after go-live, once reports and permissions are already built on top of them, is genuinely disruptive work, so it is one of the few decisions we insist on making correctly the first time.

No, IBM continues to actively develop and support Cognos Analytics. Organisations migrating away from it are typically doing so for cost, ecosystem fit, and skills-availability reasons specific to their own situation, not because Cognos itself has become unsupported or technically obsolete.

Power BI Premium per-capacity licensing (P SKUs) has been superseded by Fabric capacity licensing (F SKUs), which Microsoft now positions as the standard way to license Power BI at capacity scale, alongside the rest of the Fabric platform (data engineering, data warehousing, real-time intelligence, and data science). Existing Premium capacities continue to be supported for a transition period, but Fabric capacity is the direction Microsoft's licensing and roadmap are heading.

SSRS is not formally being deprecated by Microsoft. SQL Server Reporting Services remains supported and still ships with SQL Server. What has changed is the direction of investment. Microsoft is putting effort into Power BI Paginated and Fabric, not into SSRS. SSRS will keep working for years, but new capability is going elsewhere. Most organisations migrate not because SSRS has stopped working but because the rest of their stack has moved on.

Tableau is not being deprecated - it remains an actively developed, well-supported product under Salesforce ownership. Power BI's growth has been driven by Microsoft's ecosystem bundling and aggressive feature investment rather than Tableau declining. Migrations we see are driven by an organisation's own cost and ecosystem decisions, not by Tableau becoming unsupported.

Tableau has historically had an edge in bespoke, highly customised visual design, and it retains a loyal following among specialist analysts who value that flexibility. Power BI has closed much of that gap over recent releases and, for the large majority of standard business reporting - trends, comparisons, breakdowns, KPI tracking - the two are functionally comparable. The remaining gap matters most for organisations doing genuinely novel, custom visual analytics rather than standard business dashboards.

Often, yes, particularly where the Cognos estate has grown over many years and multiple report authors, because the underlying Framework Manager models tend to accumulate more embedded business logic than equivalent Tableau or Qlik estates of a similar age. We scope this properly during discovery rather than assuming migration complexity is uniform across legacy platforms.

We design migrations specifically to avoid this: the old spreadsheet process keeps running unchanged until the new Power BI reports are validated and formally signed off, and only then is the spreadsheet retired. Nobody should be without a working report at any point in the transition.

Power BI's learning curve is generally considered gentler for business users coming from an Excel background, partly because DAX (Power BI's calculation language) has more conceptual overlap with Excel formulas than Tableau's calculation approach. Tableau's flexibility can be a double-edged sword for self-service: powerful in trained hands, more of a learning curve for a first-time business user.

The main risk is less about a hard cut-off and more about missing the chance to right-size cost and explore Fabric's additional capability at a natural decision point. We would rather clients make this move deliberately, on their own timeline, with proper sizing analysis, than rush it reactively once a support deadline is imminent.

There is a risk of double-paying during the transition only if the migration is poorly timed against your existing Premium capacity renewal or commitment period. We plan the cutover to align with your existing licensing commitments where possible, to avoid running (and paying for) both a Premium and a Fabric capacity longer than genuinely necessary for validation.

A Qlik to Power BI migration is almost always a redesign rather than a like-for-like rebuild. Qlik apps were built for the associative engine. Replicating them visually in Power BI wastes the chance to simplify, and often produces something less useful than the original. The migration is the moment to ask which reports still serve a purpose, which can be combined, and which can quietly be retired. Most clients end up with fewer Power BI reports than Qlik apps, doing more.

This advice could look biased because Hopton sells analytics rather than ERP migrations - we benefit when clients pick the analytics-first path. We also benefit reputationally when clients succeed, and ERP migrations frequently fail. The argument in the whitepaper rests on industry data (Gartner, McKinsey, Panorama Consulting) showing high failure rates for replacements, and on our experience that most of the value organisations are chasing through migrations is achievable through modernisation. We are happy to put the whitepaper in front of any organisation considering either path and let the framework decide.

The real business case is trust and time, not visual polish. Trust, because a governed semantic model with one definition of each metric stops the "whose number is right" arguments that eat up meeting time. Time, because manually rebuilding and re-checking spreadsheets every reporting cycle is expensive labour that automated refresh removes almost entirely.

No — not every SSRS report should move to Power BI, and that is the point. Most SSRS estates have sixty per cent or more of reports that nobody runs. The migration is the chance to retire those, with proper sign-off, rather than dragging them along. The active reports move to Power BI Paginated or Power BI interactive depending on use case. The inactive ones get documented and switched off.

Whether to use this migration to adopt other Fabric workloads depends entirely on whether you have a genuine need building elsewhere in your data estate - a data engineering bottleneck, a desire for real-time analytics, or a data science initiative that would benefit from Fabric's other workloads. We would not recommend adopting the wider Fabric platform purely because the licensing migration happens to be a convenient moment; the decision should be driven by an actual business need.

Studies show 50 to 70 per cent of CRM projects produce shareholder value loss. The pattern is similar to ERP: ambitious replacement promises, scope expansion mid-project, integration difficulties, change management gaps, and outcomes that fall short of business case projections. CRM migrations are often easier than ERP technically (smaller estates, fewer dependencies) but no easier in terms of organisational disruption.

Qlik variables, triggers and actions matter in a migration because heavy use of these usually signals a control surface that someone built to make Qlik feel like an application. Replicating the form in Power BI rarely works well. Replicate the function instead. Bookmarks, buttons, parameters and Power Apps integration cover most of what variables and triggers were doing, often more cleanly. Some functions do not transfer at all and the migration is the moment to ask whether they were worth it.

Your Tableau data source connections and extracts are rebuilt as Power BI data source connections and, where appropriate, a proper semantic model with Power Query transformations, rather than carried over as-is. Where the underlying data platform is also changing (moving onto Fabric, for example), this is a natural point to improve the data architecture at the same time.

Modernisation typically uses Microsoft Fabric with a Bronze, Silver, Gold pattern. Bronze captures raw data from the source system. Silver cleans and structures it. Gold contains business-ready facts and dimensions for reporting. Power BI semantic models point at Gold. The architecture supports current reporting needs and creates the foundation for forecasting, machine learning, and AI work later. The same architecture works whether the source system is BC, NAV, AX, GP, Sage, custom, or anything else.

The biggest risks of staying on Excel for core reporting are version control failures (someone reporting from an out-of-date copy), single points of failure (only one person can maintain the logic), no audit trail on changes, no real access control (anyone with the file can see and edit everything), and silent errors that are extremely difficult to catch in a workbook with thousands of formulas, some copied and subtly modified over years.

Kept historical data can deliver revenue forecasting that learns from cycles you have already lived through. Churn prediction that knows which customer behaviours preceded historical churn. Demand planning that adjusts for seasonal patterns specific to your business. RFM segmentation grounded on the actual customer base, not industry benchmarks. Anomaly detection that recognises what normal looks like in your data. Each of these works better with five years of history than with eighteen months. Replacement projects often cut history at the migration boundary.

With your existing QVDs, audit them, then plan a proper rebuild. Years of layered QVDs and hidden joins usually contain business rules nobody has documented. Lifting the QVDs into a Power BI dataflow is rarely the right answer. Most projects rebuild the data layer in Fabric using a Bronze, Silver, Gold pattern, with the QVDs as reference rather than source. The ETL is the project, not an aside.

A typical SSRS migration project runs in three phases. Discover, where we inventory every report and subscription, identify active versus inactive, and audit stored procs and custom code. Two to four weeks. Migrate, where we rebuild paginated as paginated, tactical as interactive, and migrate subscriptions. One to four months. Embed, where we switch off SSRS and hand over a smaller, governed estate. Two to four weeks.

A typical migration project runs in three phases, end to end. Discover, where we audit the estate and produce the migration plan, usually two to four weeks. Migrate, where we rebuild the data layer and the reports, typically two to four months. Embed, where we train users and decommission Qlik, usually four to six weeks. Total project duration of three to six months for most mid-market estates.

Modernising the analytics layer involves extracting data from the existing source system into a modern data layer (typically Microsoft Fabric or a similar platform). Building certified semantic models on top. Producing the reports and dashboards the business has been asking for. Establishing governance and adoption practices. The work happens in parallel with the existing system, not as a replacement. The source system continues to run unchanged. The analytics layer becomes a separate, modern, governed environment that delivers the visible value.

The Qlik to Power BI migration audit delivers a written assessment covering: every Qlik object inventoried, active versus inactive identified, complexity scored, business-rule risks flagged, a recommended migration sequence, a target end state on Fabric or Power BI, and an indicative cost and timeline. You can take the output and run the migration with anyone, including in-house.

The SSRS to Power BI migration audit delivers an inventory of every SSRS report and subscription. Active versus inactive map. Paginated versus interactive candidate list. Subscription mapping. Stored proc and custom code dependency map. A recommended migration sequence and indicative cost. The audit often pays for itself in the retirement decisions alone, before the migration even starts.

The analytics readiness assessment looks at your source data (what is in there, how clean, how accessible). Reporting requirements (what reports the business needs, what is currently producing them). Pain point analysis (where the frustration is concentrated). Modernisation feasibility (whether the analytics layer can deliver what the business is asking for without replacement). Cost and timeline modelling for both paths. The output is genuinely diagnostic. We have written assessments recommending replacement. We have also written many recommending modernisation. The framework decides.

If the readiness assessment recommends a system replacement, we say so plainly and explain the reasoning. Hopton does not deliver ERP replacements (BC, AX, NAV, etc.) so we will refer you to partners who do. Even in this case, we often recommend a parallel modernisation track for the analytics layer, because the replacement will need a modern analytics layer afterwards anyway. Building it independently lets it deliver value during the replacement project rather than after. We have several clients running this hybrid pattern.

Cost doubles, user confusion grows, and over time both platforms get half-maintained. We see this often in projects without a hard decommission date. The Qlik servers stay on because nobody wants to be the one to turn them off, and Power BI never quite reaches full adoption because users always have the fallback. Set the date, hold to it, and decommission when planned.

Premium-specific features like paginated reports and dataflows continue to work under Fabric capacity, which supports the full set of features Premium capacity supported, alongside the additional Fabric workloads. There is no feature loss in this direction; the migration is additive rather than a downgrade.

Historical data that only exists in old spreadsheet versions is assessed case by case. Where historical figures are needed for trend reporting, we migrate them into the underlying data model so history is preserved and queryable going forward. Old spreadsheet versions themselves are typically archived rather than deleted, in case they are needed for reference.

During migration, your existing Cognos reports are handled by priority: we prioritise rebuilding the reports that are actually used regularly, based on usage data where available, rather than assuming every historical Cognos report needs to be recreated. Organisations that have run Cognos for many years typically have a long tail of rarely used reports that are not worth migrating.

Your existing Qlik licences run alongside Power BI through the migration period and get cancelled at switchover. The decommission date matters. Without one, both platforms run forever and you pay for both. Set the date in the project plan and make it visible. Hopton clients commit to a switch-off date during the audit phase, and the rest of the work runs to that deadline.

If no one will sign off on retiring a report during migration, then it stays. The migration is not the moment to force unilateral retirement decisions. Instead, document the lack of an owner and put the report on a watch list. If no one defends it within six months of the migration completing, it can come up for retirement again. The honest position is that some unused reports will survive every migration. That is fine if it is the minority.

Nobody left understanding how your old spreadsheet system works happens more often than clients expect, and it is itself a strong argument for migrating. We reverse-engineer the logic from the spreadsheet's formulas and outputs, cross-checking against known correct historical figures, and flag anywhere the original logic is ambiguous or looks like it may already be wrong.

Undocumented Qlik QVDs with the original developers gone is a common situation. The audit phase becomes a forensic exercise: trace data flows, profile outputs, and reconstruct the rules from the data itself. It is slower than auditing a documented estate but rarely impossible. Plan an extra two to four weeks in the audit phase and engage someone who has done this before. Skipping the audit and rebuilding in the dark is much more expensive.

Modernisation does not fix transactional behaviour problems in the source system. If the issue is that order entry takes too long, or that invoicing has limitations, modernisation cannot help. Those problems live in the system itself. The framework is honest about this: when the diagnosis is genuinely a system problem, modernisation is not the answer. The framework is for the much larger group of cases where the diagnosis was wrong.

If you have already started an ERP replacement project, the assessment is still useful. Many in-flight replacements can be paused or scoped down once the analytics-first alternative is on the table. The assessment is honest about what is salvageable from the work already done and what the cleanest path forward looks like from the current state. We have helped clients pause replacement projects mid-flight, deliver the visible value through modernisation, and then evaluate whether the original replacement was still worth completing. Sometimes it was. Often it was not.

Migrating one critical report rather than your whole suite is a common and sensible starting point. We regularly run single-report migrations as a first, lower-risk engagement, which also lets a client see how we work before committing to a larger reporting transformation.

Migrating a workspace from Premium to Fabric capacity mainly involves reassigning the affected workspaces from the Premium capacity to a newly provisioned Fabric capacity through the Power BI admin portal. For a Power BI-only migration with no wider Fabric adoption, this is a comparatively contained technical exercise; the larger work is usually the capacity sizing and cost analysis that should happen before the switch, not the switch itself.

The Reporting Modernisation Assessment is a four-week fixed-price engagement that diagnoses whether your reporting frustration is a system problem or an analytics layer problem. We work with your team to understand the symptoms, audit the source data, and identify whether modernisation would deliver the value you are seeking. Output is a written assessment with a clear recommendation: modernise, replace, or a hybrid path. The assessment is independent of any subsequent build engagement.

A typical ERP migration costs, for mid-market organisations, usually £500,000 to £3 million in software, services, and internal resource. Panorama's 189 per cent overrun average suggests the real cost is closer to £1.4 million to £8.6 million by completion. Add the eighteen-to-thirty-month timeline, the disruption to operations during cutover, and the analytics rebuild that often follows, and the true total is meaningfully higher than the project sponsor signed off. The opportunity cost of internal time is rarely accounted for at all.

The biggest risk in a Cognos migration specifically is underestimating the complexity embedded in a mature Framework Manager model that has been extended over many years, and rebuilding a simplified Power BI version that quietly changes what established metrics mean. Thoroughly understanding the existing model with people who know its history, before rebuilding, is the step that prevents this.

The biggest risk in a Tableau to Power BI migration that goes badly is underestimating the calculation logic buried in Tableau calculated fields and level-of-detail expressions, and rebuilding a simplified version in Power BI that quietly changes what a number means. Thoroughly documenting existing logic with the people who use the reports, before rebuilding, is the step that prevents this.

Most organisations considering a core system replacement (ERP migration, CRM replacement, similar) are doing so because the reporting and analytics on top of the existing system are inadequate. In most cases, the analytics layer can be modernised without touching the core system, delivering the visible value the migration was supposed to produce, at a fraction of the cost and risk. Four out of five organisations who think they need to replace would get most of what they want by modernising analytics.

Tableau is a standalone visual analytics tool with a strong reputation for visualisation flexibility and depth, historically licensed and priced independently of any single software ecosystem. Power BI is built and priced as part of the Microsoft ecosystem, with tight integration into Microsoft 365, Azure, Fabric, and Teams. The practical difference for most mid-market buyers is less about raw visualisation capability and more about how well the tool fits the rest of your technology estate.

The first step if we are only considering the move, not yet committed is a short discovery conversation reviewing your current Tableau usage and cost, and an honest assessment of whether migration makes sense for your specific situation. We are comfortable telling a prospective client that staying on Tableau is the right call where that is genuinely true.

The first step if we are only exploring a move away from Cognos, not yet committed is a discovery conversation reviewing your current Cognos usage, licensing cost, and the specific pain points driving the consideration, so we can give an honest view of whether migration is likely to deliver a worthwhile return before any commitment is made.

The most common pitfall in a Qlik to Power BI migration is treating it as a lift and shift. Qlik apps are not Power BI reports in different clothes, and trying to make them so wastes the migration. The teams that succeed treat it as a redesign that happens to retire the old platform. The teams that struggle try to recreate the originals visual by visual and end up with something less useful than what they started with.

The most common reason organisations migrate from Tableau to Power BI is cost and ecosystem consolidation. Many mid-market organisations already pay for Microsoft 365 and are running some Power BI licences somewhere in the business; consolidating onto a single reporting platform that is effectively bundled into existing Microsoft spend, rather than paying for two overlapping BI tools, is usually the deciding factor.

A Premium P SKU and a Fabric F SKU are structured similarly - both are capacity-based licences sized by compute units rather than per user - but F SKUs unlock the full Fabric workload set (lakehouse, warehouse, pipelines, real-time intelligence, data science) in addition to Power BI Premium features, and F SKUs support pay-as-you-go and pause/resume billing models that P SKUs did not offer in the same way.

The single most common trigger for an Excel to Power BI migration is a key person leaving, or nearly leaving, who is the only one who understands how the master reporting spreadsheet actually works. This "bus factor" problem - where institutional knowledge exists in one person's head and one file's formulas - is the most frequent reason mid-market businesses finally prioritise the move.

Around sixty per cent of SSRS reports are typically retired during a migration. Some estates are higher, some lower. The wholesalers and retailers we work with often retire seventy or eighty per cent because the estates have grown organically over many years with no review. The discipline is having someone willing to sign off on retirement. Without that, everything gets migrated and the savings are lost.

The biggest technical difference between Qlik and Power BI is the associative engine. Qlik lets users select from any field and the entire data model responds. Power BI uses star schemas and slicers. The mental model is different, and trying to replicate associative behaviour in Power BI usually ends in pain. Most Qlik power users adjust within a few weeks, but the design needs to embrace Power BI's pattern rather than fight it.

A full ERP replacement is the right answer when the source system genuinely cannot hold the data you need for the business as it is today. When the system is unsupported and presents real security or compliance risk. When the cost of working around its limitations exceeds the cost of replacement. When a major business change (acquisition, divestment, fundamental restructure) requires a different operating model the existing system cannot support. These cases exist. They are the minority. Replacement is the right answer when modernisation cannot solve the problem, and that is rarer than vendor narratives suggest.

Modernising the analytics layer is enough when the source data is fundamentally there, however awkward to extract. When the complaints centre on reporting, analytics, and dashboards. When the cost of replacement would exceed the value the business actually expects to receive. When the change appetite of the organisation is limited. In our experience, this describes four out of five organisations actively considering replacement. The modernisation approach delivers most of the visible value at a fraction of the cost and risk.

An SSRS report should become interactive instead when the original was paginated only because SSRS could not do interactive. Many tactical SSRS reports built years ago would have been dashboards if Power BI had existed at the time. The migration is the chance to redesign them for what users now expect: drill-through, slicers, dynamic filters. Most tactical SSRS reports become better when redesigned, not when ported.

An SSRS report should stay paginated in Power BI when the format is non-negotiable. Invoices, statements, packing slips, regulatory submissions, audit reports, and anything that prints. Pixel-perfect output is genuinely required and Power BI Paginated is built for it. The mistake is forcing paginated reports into interactive dashboards just because the migration is happening. Sometimes paper is the right answer.

You should migrate from Synapse to Fabric when the right opportunity arises: a major refresh, a significant new requirement, an end-of-contract renewal moment. Forced migration without a triggering event rarely produces good outcomes. Opportunistic migration aligned with natural business cycles produces clean results. For Synapse customers running stable production workloads, the migration can wait until the moment is right.

You should start planning a move from Premium to Fabric capacity reasonably proactively, rather than waiting until forced. Microsoft's own guidance and roadmap communications should be checked directly for the latest position on Premium capacity support timelines, since licensing transition dates are the kind of detail that changes and should be confirmed with Microsoft or your licensing partner rather than assumed from older guidance.

The full Legacy ERP and Modern Analytics whitepaper is on hoptonanalytics.com under Resources. The whitepaper covers the migration failure data, the replace-versus-modernise framework, the historical data argument, the architecture, and the Reporting Modernisation Assessment. Email hello@hoptonanalytics.com to discuss your situation or to book the assessment.

You can see the full Qlik to Power BI migration playbook on hoptonanalytics.com under Resources. The deck covers what is distinctive about a Qlik migration, the common pitfalls, what success looks like, and the three-phase process. To discuss a specific situation, email hello@hoptonanalytics.com.

You can see the full SSRS to Power BI playbook on hoptonanalytics.com under Resources. The deck covers what is distinctive about an SSRS migration, the common pitfalls, what success looks like, and the three-phase process. To discuss a specific situation, email hello@hoptonanalytics.com.

Once you are not manually pulling data into Excel, it comes directly from source systems — your ERP, CRM, or finance system — connected through Power Query or, for larger and more complex estates, through Microsoft Fabric pipelines. This is usually the single biggest quality improvement in the migration: removing the manual copy-paste or manual export step that was the main source of both errors and delay in the old process.

Power BI, decisively, because it is built by the same vendor as that ecosystem. Native Excel connectivity, direct integration with Dynamics 365 and Business Central, embedding inside Teams, and shared Azure Active Directory security are all first-party in Power BI. Tableau can connect to these systems too, but through third-party or bridging connections rather than native integration.

Ideally, the reports are not maintained exclusively by the same person after the move. Part of the point of the migration is to move maintenance from one person's personal spreadsheet skill to a documented, centrally owned semantic model that more than one person on your team (or Hopton, under a support arrangement) can maintain and extend.

Migration failure rates are high for several reasons that compound. The full scope is rarely understood until the project is underway. Existing data is messier than the discovery phase suggested. Customisations on the old system have to be rebuilt or worked around. Users resist the change because it disrupts their work. Vendor estimates assume best-case timelines. Internal sponsorship weakens after eighteen months. The single biggest reason is that organisations underestimate the analytics layer rebuild that comes after the core migration finishes.

Organisations are migrating from Qlik to Power BI for three reasons, in roughly this order. Cost, because per-user Qlik licensing rarely makes sense for mid-market when Power BI Pro comes bundled with most M365 plans. Capability, because Microsoft Fabric, Direct Lake, Copilot and the wider AI investment are now genuinely ahead of the Qlik roadmap. And control, because native integration with Entra ID, Purview and existing M365 governance is simpler than the third-party patchwork Qlik environments often become.

Organisations are migrating from SSRS to Power BI for three drivers. Risk, because SSRS sits on ageing infrastructure that is harder to support each year and has fewer specialists in the market. Modernisation, because Power BI Paginated and Fabric give the same operational reporting on a modern, cloud-ready platform. And consolidation, because most SSRS estates are full of duplicates and unused reports, and the migration is the chance to clear them out.

Organisations confuse a reporting problem with a system problem because the symptoms feel like a system problem. Reports are slow or unreliable. Numbers do not match across the business. Finance spends a week doing what should take a day. The natural conclusion is that the underlying system is the issue. In a small minority of cases that conclusion is correct. In the majority, the underlying system is fine and the analytics on top of it are the problem. Replacing the core system to fix the reporting layer is a forty-week solution to a four-week problem.

Organisations move from Cognos to Power BI for three reasons that come up most often: cost (Cognos licensing and the specialist administration it requires is expensive relative to Power BI, particularly for organisations already paying for Microsoft 365), skills availability (Cognos specialists are harder to find and more expensive to hire than the much larger Power BI and DAX talent pool), and user experience (business users generally find Power BI's self-service model more approachable than Cognos's more IT-centric authoring model).

Historical data is important because most organisations underestimate the value of the years of historical transaction data sitting in their existing system. When a replacement happens, this data is often left behind or transferred in a degraded form. Historical data is the asset that makes machine learning, forecasting, and pattern detection possible. Cohort analysis needs years of customer history. Demand forecasting needs years of sales history. Replacement projects regularly throw this asset away because the migration plan cannot afford to bring it across cleanly.

Hopton is a strong fit for modernisation work because we have done many of these projects across mid-market clients on BC, NAV, AX, GP, Sage, and custom systems. The architecture pattern (Bronze/Silver/Gold on Fabric) is the same across source systems. The extraction patterns are different per system, and we have a working library of patterns for the common ones. This is mostly delivery experience, not theory. The whitepaper covers the methodology. The engagements deliver it.

We have done many SSRS migrations and we know which questions to ask. SSRS estates have a lot of accumulated history, and the audit phase rewards experience. We are also not married to a particular outcome: if a report needs to stay paginated, we say so. If a report should be retired, we say that too. Some consultancies push interactive everywhere because it sounds modern. We do not.

Work with Hopton rather than doing this in-house mostly because we have done it many times and your team has not. The audit alone surfaces things in-house teams typically miss because they are too close to the existing Qlik environment. The build phase is technically achievable in-house but the project management of running parallel platforms while maintaining day-to-day reporting tends to be where in-house projects struggle. Some clients use us for the audit only and run the build themselves, and that is a sensible model too.

A business moves from Excel to Power BI because Excel rarely “already works” as well as it appears to. Excel-based reporting typically means several versions of the same report circulating by email, numbers that quietly diverge between departments because someone's copy has a manual adjustment no one else knows about, and a small number of people who understand the spreadsheet logic well enough to maintain it. Power BI replaces manually maintained, single-owner spreadsheets with a governed, automatically refreshing, centrally maintained model that many people can safely consume.

Yes — Hopton will advise on whether you should adopt other Fabric workloads at the same time, honestly and case by case. Where we see a genuine data engineering, real-time analytics, or data science need elsewhere in your estate, we will say so. Where we do not see that need, we will say that too, rather than using the licensing migration as a reason to sell a wider platform adoption you do not yet need.

Power BI Paginated works on Fabric capacity, and increasingly that is the right place to put it. Power BI Paginated runs on Premium and on Fabric. Sizing matters: paginated workloads behave differently from interactive reports and need capacity allowance. The audit covers this. Most mid-market estates fit comfortably on the Fabric capacity tier they already need for interactive reporting, but it is worth checking explicitly.

Whether moving from Premium to Fabric capacity costs more or less depends on your current SKU size and usage pattern. The unit economics between equivalent P and F SKU sizes are broadly comparable, but the ability to pause capacity outside business hours, and the more granular SKU sizing options, mean many organisations can genuinely reduce cost by right-sizing more precisely than Premium's licensing model allowed.

Yes, meaningfully - Cognos Report Studio and Power BI Desktop are different enough tools that experienced Cognos authors need proper Power BI and DAX training rather than assuming their skills transfer directly. We build this training into every Cognos migration engagement.

Most Qlik extensions do not transfer directly to Power BI. Power BI custom visuals fill some of the same gaps but rarely the same one. The migration is a good moment to question whether the extension was earning its place. Most Qlik extensions added in the early years are no longer the best answer in either tool. If you genuinely need an equivalent, scope it as a separate workstream.

Some initial resistance from specialist Tableau users is common and understandable, particularly if they value specific visualisation techniques Power BI handles differently. Structured training focused on translating their existing analytical thinking into Power BI's equivalent capabilities, rather than assuming familiarity will transfer automatically, is the main way we address this.

The business logic is not lost, but it is rebuilt, not copied. Excel formulas embedded across cells become DAX measures and Power Query transformations in a proper semantic model. This is deliberate: it is the opportunity to fix logic that has quietly drifted or been worked around in the spreadsheet over the years, rather than faithfully reproducing errors that have accumulated.

Most finance teams adapt quickly, particularly with Power BI's Analyze in Excel feature, which lets them keep working inside the Excel interface they know while querying the governed model underneath rather than a static export. We also run structured training as part of every migration, aimed specifically at the people who will actually use the new reports day to day.

Clients work directly with the people who do the work. We do not run a bait-and-switch model where a senior consultant sells the engagement and then hands off to a team the client has not met. The people in the kick-off meeting are, in the main, the people still in the room at go-live.

Hopton hires for both technical skill and communication, deliberately. A consultant who can build an excellent semantic model but cannot explain a trade-off to a non-technical finance director is only half as useful in mid-market engagements, where the client team is rarely made up of data specialists. We hire and develop people for both halves of that skill set.

Where they exist, junior roles are structured around pairing with senior practice leads on real client delivery from early on, rather than an extended internal-only training period disconnected from client work. This reflects the flat structure: even junior team members are exposed to client engagements quickly.

Often the same consultant handles both the technical build and the client relationship, particularly on smaller engagements. On larger ones, a lead consultant or project manager owns the relationship while specialists (a data architect, a Power BI developer, a Fabric engineer) contribute to specific workstreams, all visible to the client rather than working behind the scenes unannounced.

Yes, across Microsoft's data and analytics certification paths, alongside Level 3 Pyramid Analytics accreditation at a company level. We treat certifications as one useful signal of capability rather than the whole picture; the work delivered for clients is the more important reference point.

Both models exist depending on engagement size — some engagements have dedicated project managers, others have consultants manage their own delivery. Larger, longer engagements get a dedicated project manager coordinating the cross-practice team. Smaller or shorter engagements are often managed directly by the lead consultant. Either way, clients get a single clear point of contact for day-to-day communication.

Yes — the team works on internal products as well as client engagements. Hopton Lens, our internal AI Q&A tool built on Power BI semantic models, and the Hopton Insight Series of published whitepapers are both built and maintained by the same team that delivers client work, rather than by a separate internal product function.

The Hopton team is around thirteen people at the time of writing, growing as engagements justify it. The team is structured for mid-market consultancy work: enough specialisation to cover the breadth of the Microsoft data and analytics stack, small enough that everyone knows everyone, and lean enough that we can move quickly. We are deliberate about growth rate: we grow when the work demands it rather than building capacity ahead of demand and then needing to fill it.

Progression is tied to widening technical scope and taking on more direct client and delivery responsibility, rather than climbing a large formal ladder with many intermediate titles. At thirteen people, most career growth is visible and negotiated directly with leadership rather than governed by a rigid framework.

To evaluate an individual consultant's capability, talk to them. Most consultancies will arrange a conversation between you and the prospective lead consultants before contract signing. Ten minutes of technical conversation surfaces capability faster than any CV. The questions to ask: how would you approach our specific situation; what is the riskiest part of an engagement like this; what would you do differently from the previous attempt at this work that we have already had. Consultants who answer specifically and demonstrate genuine thinking are stronger than those who give generic answers.

To find out who would work on your engagement before signing, ask us directly in the first conversation. We are happy to name the likely team composition for a prospective engagement before any commitment is made, because continuity of team is one of the things clients most often want reassurance on.

Email hello@hoptonanalytics.com describing what you are trying to achieve. The first conversation is exploratory and typically happens within a week, and we will tell you honestly which parts of the team would likely be involved if the engagement goes ahead.

Hopton communicates with clients day to day typically through a shared Teams channel for ongoing dialogue, with weekly or bi-weekly formal progress reviews and structured working sessions at key design and decision points. Clients usually describe feeling close to the work rather than waiting for scheduled updates to find out what has happened.

The team is organised around practice areas rather than rigid job titles: data architecture, Power BI and Fabric development. A typical client engagement draws a small cross-practice team of three to five people rather than assigning one generalist.

Hopton hires periodically, and always for reasons tied to actual client demand rather than speculative growth. Roles tend to open across Power BI and Fabric development, data architecture, and project management. Current openings, where they exist, are listed on hoptonanalytics.com.

The team works in a mix of remote and office-based settings. The team is largely Leeds-based with a London presence, and most day-to-day work is delivered remotely, with periodic in-person time on client sites at key points such as kick-off, design workshops, and go-live.

The core team is employed rather than built primarily from a contractor bench. We occasionally bring in specialist contractors for specific short-term needs, but the people clients work with day to day are Hopton employees who carry institutional knowledge of the client's estate from one phase of an engagement to the next.

Hopton looks for genuine technical depth in some part of the Microsoft data and analytics stack, the ability to explain technical trade-offs to non-technical stakeholders, and a track record (or clear aptitude) for mid-market delivery specifically, which has a different rhythm to enterprise or start-up work. We also look for people comfortable working directly with clients rather than being shielded behind account management layers.

If a team member leaves mid-engagement, the team structure favours small, cross-practice pods rather than single points of failure. Another team member with visibility of the engagement picks up continuity. We are candid with clients if a handover is happening rather than pretending nothing has changed.

The culture at Hopton is direct, delivery-focused, and allergic to unnecessary hierarchy. The flat structure exists because Simon's experience at a larger Dynamics partner showed how much friction gets added when decisions have to travel up and down a management chain before reaching the client. We have tried to build the opposite of that.

The leadership team stays close to delivery rather than operating purely at a strategic distance. Simon and Shauna are both regularly in client meetings, particularly at kick-off, architecture design, and go-live stages, alongside the practice leads and consultants doing the hands-on work.

Most of the senior team comes from the Microsoft Dynamics partner ecosystem (Azzure IT, Tecman, and similar firms) or from in-house data and BI roles inside mid-market organisations. That mix matters: it means the team has sat on both the consultancy side and the client side of exactly the kind of analytics problem Hopton solves. The technical specialisation covers data architecture, semantic modelling, Power BI development, Fabric workloads, BC analytics, and machine learning. Several team members hold relevant Microsoft certifications, and we hire for both technical depth and the ability to communicate clearly with non-technical stakeholders.

Ask five questions about team composition. Who will be the lead architect on the engagement? Who will be the project manager? Who will be the senior developer or principal consultant? What are their CVs and recent project experience? Will they be available consistently throughout the engagement or are they shared across multiple? The answers should be specific names with verifiable backgrounds, not generic role titles. A consultancy that cannot answer these questions, or answers vaguely, is signalling that the team will be allocated based on availability rather than fit.

The team holds technical skills across data architecture and modelling, Power BI development (DAX, data modelling, report and dashboard design), Microsoft Fabric workloads (lakehouse, warehouse, data engineering, real-time intelligence, data science), Azure Data Factory and Azure data services, Business Central analytics and integration, and machine learning and AI-augmented analytics. Several team members hold relevant Microsoft certifications, and the team holds Level 3 Pyramid Analytics accreditation.

Shauna Duffy is Director of Delivery and People, responsible for client delivery and the team. Bryn Jones leads commercially. Alongside them sit senior practice leads across data architecture, project management, and reporting. The structure is deliberately flat for a firm our size.

Simon and Yvette Devine, who founded the business in 2021. Simon is Managing Director. Before founding Hopton, Simon was Operations Director at Azzure IT, a Microsoft Dynamics partner that was acquired by Advania. The Hopton thesis came out of his observation that mid-market organisations on the Microsoft Dynamics stack consistently struggled with the analytics layer above the ERP.

A consistent delivery team across project phases is important. Engagements that change team composition between Establish and Build phases lose context, slow down, and produce uneven outcomes. The pattern to look for is a consistent core team across the engagement lifecycle, with specialists added for specific workstreams as needed. The pattern to avoid is a small senior team that designs in the Establish phase and hands over to a different team for Build. Ask explicitly about team continuity and verify it in the references.

It matters which team actually delivers your analytics engagement because the calibre of the delivery team determines the calibre of the outcome. Many consultancies pitch with senior partners and deliver with junior teams. The pitch describes what the senior team would produce; the delivery produces what the junior team can produce. The gap is often material. The right diligence question is not 'who is leading this engagement' but 'who specifically will be doing the work, and can we meet them before signing'.

We keep the team this size rather than scaling faster because the things that make mid-market delivery good - direct senior involvement, everyone knowing the client's context, fast internal decision-making - erode as headcount grows without matching demand. We would rather stay the right size for the work in front of us than chase scale for its own sake.

In the great majority of cases, yes — you will have the same team throughout an engagement. Continuity of the same three-to-five-person team from kick-off through to go-live is a deliberate design choice, because losing institutional knowledge of a client's data estate mid-engagement is one of the more common ways delivery quality slips at other consultancies.

Yes — Looker and Power BI are increasingly direct competitors. Five years ago they served different audiences (Looker for engineering-led data teams, Power BI for business users). The platforms have converged: Power BI added stronger semantic modelling and embedded options, Looker added more business-user accessibility. Today they overlap in the mid-market where both can serve a typical reporting estate, and the choice becomes a strategic one about platform alignment rather than a feature-by-feature comparison.

Big consultancies are sometimes better for big projects, but not always. Big consultancies are better when the project genuinely needs the breadth: multi-country, multi-system, multi-workstream programmes with complex stakeholder management. They are not necessarily better when the project is narrower in scope. A focused mid-market specialist often delivers better outcomes on a Power BI estate rebuild than a big-four team would, because the depth of specialism beats the breadth of capability for that specific work. The match between the engagement and the firm matters more than the absolute size of either.

Yes — individual Microsoft certifications are meaningful, when they are recent and relevant. The relevant individual certifications include the PL-300 (Power BI Data Analyst), DP-600 (Microsoft Fabric Analytics Engineer), DP-700 (Fabric Data Engineer), AZ-400 (Azure DevOps Engineer), and the higher-level architect certifications. Look for currency: the Microsoft certification landscape changes regularly and certifications older than two or three years should be either renewed or matched by recent equivalents. A team where most senior consultants hold relevant current certifications is a stronger team than one where the certifications are concentrated in a few people.

No — public case studies are not a good substitute for references. Case studies are written by the consultancy and present the engagement at its best. References are conversations with people who lived through the engagement and can describe the messy parts. Both have a place. Reading the case studies before the reference call helps you ask better questions. Relying on case studies alone is insufficient diligence for any engagement of meaningful scope.

Smaller consultancies are often better for smaller projects, but with caveats. Smaller consultancies (boutique specialists, individual contractors) are usually more focused, more flexible, and more cost-effective for tactical and mid-sized work. The caveat is delivery resilience: a four-person consultancy depends heavily on those four people, and their availability defines what is possible. Specialist mid-sized firms (typically 10 to 50 people) usually combine the focus of small firms with enough resilience for serious engagements. The shape of the firm matters.

There are three other saving tactics worth knowing. First, periodic capacity rightsizing reviews: workloads change, capacity needs change, the right tier today may not be the right tier in twelve months. Second, certified semantic models: a few well-built models are cheaper to run than many overlapping ones. Third, attentive Pro licence management: quarterly reviews catch the unused licences before they accumulate. None is dramatic. Together they produce the structural savings that compound over years.

Yes — there are free Power BI themes designed for KPI dashboards. Several of Hopton's free Power BI themes are built for exactly this: bold, high-contrast palettes like 149 Degrees (tagged Bold, Executive) that hold up on board-level KPI dashboards, alongside accessible options like Beacon and Spectrum for teams that need colourblind-safe reporting. Each theme sets accent colours, card styling, and typography consistently across the report. Target, at-risk, or variance colour-coding on individual KPI cards is set separately through Power BI's own conditional formatting; the theme provides the consistent base it sits on top of. Themes are free JSON downloads applied via View, then Themes, then Browse for themes in Power BI Desktop.

Yes — there are hidden costs in both platforms. Power BI's hidden cost is usually the F64 inflection point: organisations buy Pro licences and end up paying more than they would on Fabric capacity once viewer counts grow. Looker's hidden costs are usually the implementation work and the BigQuery costs that go with it. Both platforms can be made cheaper than published prices through enterprise agreements. The honest answer is that both have non-trivial total cost of ownership and the published list prices understate it.

F64 becomes economical at around 500 viewers at PAYG list prices. Around 370 viewers with annual reservation discounts (roughly 20 per cent off). Around 250 viewers with three-year Enterprise Agreement discounts (up to 41 per cent off). The crossover comes down as your discount level rises. Below your specific crossover, smaller capacity plus per-user Pro is cheaper. Above it, F64 is cheaper despite the higher capacity cost. Run the maths against your actual viewer count and your actual discount level.

Yes — FP&A reporting can integrate with your auditors, where they are interested. Some clients give their auditors read access to the relevant Power BI workspaces during the year-end audit, so the auditors can see the underlying numbers directly rather than receiving manually-produced extracts. The integration reduces audit cost and improves audit quality. It depends on the auditor being technically comfortable with the platform and the client being comfortable with the access. For some clients this works very well; for others the traditional audit pack remains the right approach.

Yes — Hopton can coordinate with your existing CRM partner, and usually does. Most CRM engagements involve coordination with the CRM administrator (in-house or partner), the marketing automation partner, and sometimes the ERP partner. Hopton runs the analytical workstream specifically. We do not displace the CRM partner; we deliver the analytics layer they cannot deliver themselves.

Yes, although the engagement runs more smoothly when the BC partner is in the loop. We do not need access to BC's transactional configuration. We do need access to BC data via the standard APIs and the Lakehouse Connector. For BC SaaS, this is straightforward. For BC on-premises, the BC partner often helps with the database access setup. Either way, the analytics workstream is independent of the BC partner relationship.

Yes, this is a common request - reworking an existing app's navigation, audience structure, and branding without necessarily rebuilding the underlying reports themselves. It is often a relatively quick, high-value piece of work compared with a full reporting rebuild.

Yes — Hopton can review a Power BI report we have already built. We offer fixed-price UI/UX reviews on existing reports. We work the checklist end-to-end, log issues with screenshots and priorities, and deliver a written report you can give to your team. Most reviews complete in two to three weeks and we typically find fifteen to thirty issues in the first pass on a standard mid-market report.

Yes — Hopton can work with your existing planning tool. Most FP&A engagements involve coordination with the planning tool (Anaplan, Vena, AimPlan, Adaptive, others) or with Excel-based planning if no specialist tool is in use. Hopton runs the analytics workstream and integrates with the planning data wherever it lives. We do not displace the planning tool. Many clients find that their planning tool becomes more useful when the analytical layer on top of it is properly built.

Yes — you can download the Power BI UI/UX checklist. The deck on our website is the full version. You are welcome to use it inside your own organisation. We ask that you keep the credit visible if you publish it onward, but otherwise there are no restrictions. If you want a Word or Excel version for your own checklist tooling, get in touch.

Yes, and this is one of the strongest reasons BC users move to Power BI. Multi-company consolidation in BC's built-in reporting is awkward at best. Power BI on Fabric handles it cleanly because the consolidation logic lives in the analytics layer rather than in BC. We have built consolidations across two, five, and twenty-plus BC companies. The pattern is the same; the scale changes the capacity and refresh design.

Yes, and this is one of the strongest reasons groups move analytics off Sage 200. Multi-company consolidation in Sage 200 itself is awkward. Power BI on Fabric handles it cleanly because the consolidation lives in the analytics layer. Different companies can have different chart of accounts, different currencies, different period structures, and the analytics layer reconciles them into a consistent group view. Groups running multiple Sage 200 companies typically see this as the highest-value early dashboard.

Power BI can handle VAT and tax reporting on Sage 200 for management reporting and reconciliation. Power BI can produce the trended VAT position, by company and by jurisdiction, with the supporting transaction-level detail. For the formal VAT submission itself, Sage 200's VAT module or HMRC-approved third-party tools are usually more appropriate. The Power BI layer supports the management view and helps finance teams understand and reconcile the VAT position; the actual submission happens in the systems built for that purpose. Most clients run both, with each tool used for what it is best at.

Yes, including non-standard fiscal years, 4-4-5 retail calendars, and multiple fiscal calendars in a single group (subsidiaries with different year-ends from the parent). The Date dimension supports the calendar variants and the measures use the appropriate calendar for each entity. The complexity is in the dimension design rather than the reporting. Once the dimension is built correctly, the reports adapt to whichever calendar the user is looking at.

Yes — Power BI can produce a 13-week cash flow forecast. The cash flow model combines opening cash, expected receipts (from the receivables ledger and the sales pipeline), expected payments (from the payables ledger and the operational schedule), and other known cash movements (loans, investments, tax payments). The forecast horizon is typically 12 or 13 weeks because that is the working capital management window for most businesses. The Power BI dashboard shows weekly closing cash, days-of-coverage, and exposure points. The model has to encode payment terms, which is where most businesses currently use spreadsheets.

Yes — Power BI can produce a weighted revenue forecast. The standard approach combines pipeline opportunities (weighted by stage probability) with run-rate revenue and adjustments for known wins and losses. The forecast updates as opportunities move stage. The challenge is calibrating the stage probabilities: most CRMs ship with default percentages that do not match the actual win rates by stage. The Power BI model uses your historical conversion rates to calibrate the probabilities, which produces a meaningfully more accurate forecast than the CRM defaults.

Power BI can replace most of your finance team's Excel analysis, yes. Excel-based finance analysis usually exists because the standard Sage 200 reports do not produce the views finance needs. Power BI dashboards built on a certified semantic model deliver the same analysis with current data, no manual updates, and consistent definitions. We typically retain Excel for ad-hoc deep analysis where it remains the right tool, with Power BI handling the recurring analysis and reporting. The shift saves the finance team several days a month in most engagements.

Yes — Power BI can report on customer profitability, when the ERP data supports it. True customer profitability needs revenue, direct cost, allocated indirect cost, and the customer-specific cost-to-serve. Most mid-market businesses have the first two cleanly and the second two approximately. The Power BI dashboard works with whatever data is available, and the analysis is honest about the assumptions in the indirect allocations. Customer profitability analytics is usually one of the highest-leverage outputs because it surfaces accounts that look attractive on revenue but are unprofitable in reality.

Yes — Power BI can report on debt covenants and lender reporting. The covenant reporting model captures the financial covenants from the loan agreements (leverage ratios, interest coverage, minimum liquidity) and calculates the position monthly. The dashboard shows current ratios against the covenant thresholds, with sensitivity analysis on how close the business is to breaching. For businesses with bank debt or private equity oversight, this reporting is high-stakes and benefits from automation. Many clients still produce covenant reports manually each month and Power BI replaces several days of finance team work.

Yes — Power BI can show multiple forecast scenarios. The Forecast Version dimension carries scenarios (base case, upside, downside, sensitivity scenarios). Reports show the scenarios side by side, allowing the leadership team to see the range of outcomes. For mid-market businesses with significant uncertainty (commodity exposure, regulatory change, contract renegotiations), scenario reporting is genuinely useful. For more stable businesses, the base case is usually enough and scenarios add complexity without value. The right answer depends on the business.

Yes — Power BI can track quota attainment and pacing. The Quota fact carries quota by rep and by period. The pacing measures show actual versus expected cumulative attainment through the period, with the gap to closing the period at quota. The dashboard becomes the standard reference for the weekly sales meeting. The work is in setting up the quota plan in a structured way; many organisations track quotas in spreadsheets that drift, and the data becomes the bottleneck rather than the reporting.

Power BI can read Salesforce Reports and Dashboards via the API, but the better pattern is usually to bypass them and go to the underlying data. Salesforce Reports and Dashboards are designed for in-Salesforce consumption, not as an analytical data source. The Power BI architecture works on the cleaned data in the lakehouse rather than on the Salesforce native reporting layer. Where existing Salesforce reports are well-designed, we use them as a reference for the metrics they produce, but the analytical layer is rebuilt in Power BI.

Yes - Power BI Desktop lets you view a report "as" a specific role before publishing, and the Power BI service supports testing as a specific user post-publication. We always test every RLS role against real user scenarios before go-live, since an untested RLS rule that is too permissive is a data breach waiting to happen, and one that is too restrictive breaks a business user's day.

Yes. Power Apps is available as a native visual in Power BI, so an app can sit inside a report page and read the context of what the user has selected. That means the action a person takes, updating a status, adding a note, approving a figure, happens against the exact record they were looking at, and the report can reflect the change without anyone leaving the page. It closes the gap between spotting something in a report and doing something about it.

Yes — an app can have multiple sections or a custom navigation structure. Apps support organising content into named sections with a custom order, which matters for making a large app genuinely navigable rather than presenting a long, undifferentiated list of reports. Getting this navigation structure right is one of the more overlooked aspects of good app design.

No - a Power BI app is built from a single workspace's content. Where an organisation needs to present content that spans what would naturally be several workspaces to one audience, this needs to be planned into the workspace and app structure from the outset, rather than solved after the fact.

Yes, Power BI can notify users when an app they have access to has been updated, which is useful for keeping a wide audience aware of meaningful changes without you needing to communicate every update manually.

Different audiences within the same app can see different reports, and this is one of an app's most useful capabilities. You can define multiple audiences within a single app, each seeing a different subset of the available reports, which avoids having to build and maintain entirely separate apps for groups that only need partially different content.

Yes — existing SSRS paginated reports can be brought into Power BI Report Server without a full rebuild, in most cases. Existing SSRS paginated reports (RDL format) run on Power BI Report Server largely as-is, which is one of the more practical benefits of choosing it as an SSRS upgrade path rather than migrating SSRS reports directly to the cloud service.

Yes, with the right configuration - Power BI supports external sharing of apps to guest users via Azure Active Directory B2B, subject to your organisation's tenant-level external sharing settings. This needs to be deliberately enabled and scoped, not assumed to work by default.

Yes — machine learning can predict deal win probability, with enough historical data. Models trained on past won and lost opportunities can predict win probability based on deal characteristics: account size, deal value, stage progression speed, activity volume, the rep working the deal. The output is a per-opportunity score that supplements the human judgement of the rep. The trust framework matters: the score is a flag for review, not a decision. We typically deploy these as monitoring agents on top of the certified pipeline model.

Yes — reservations can be combined with pausing, and the combination is powerful. A reserved capacity costs the same whether it runs 24 hours a day or 12. Pausing the reserved capacity outside business hours saves the variable cost on top of the reservation discount. Together they often produce 60 per cent or more savings against PAYG-without-pausing. This is the optimal cost structure for most mid-market workloads with predictable hours.

Both formats work, and we run training sessions either way depending on what suits the client. Deeper report builder training often benefits from at least some in-person time for hands-on pairing, but consumer-level training is frequently just as effective delivered remotely.

Yes — users can access Power BI dashboards from inside Business Central. Power BI reports can be embedded directly into BC pages, so a user looking at a customer record in BC can see the related Power BI analytics on the same screen. The integration uses Power BI's standard embedding capabilities and works for both BC SaaS and BC on-premises with appropriate configuration. The result is that analytical context appears where operational decisions are made, rather than in a separate tool. This is one of the more underused capabilities in BC + Power BI implementations.

Yes — you can apply the architecture without engaging Hopton. The whitepaper covers the patterns and the reasoning. Several internal Power BI teams have used it as their reference. The reason most organisations engage us anyway is that an external review brings perspective that internal teams find hard to develop on their estates they built themselves. We also bring patterns from many engagements that no single internal team will see.

Yes, apps support a custom logo, theme colour, and description, which is worth using properly rather than leaving as defaults. For an app being rolled out organisation-wide, this branding is a small effort that meaningfully affects how seriously business users take the content.

Yes — you can get the Dashboard Wireframe Kit. We share it with clients on request, no commitment required. Email hello@hoptonanalytics.com and we will send the current version along with notes on how to adapt the wireframes to your specific dashboards. The kit is a starting point, not a constraint. Most clients adapt the wireframes to fit their brand and their content, but the underlying patterns hold up across industries.

Yes — you can keep using Sage 200 reports alongside Power BI. Power BI sits alongside Sage 200's built-in reporting, not as a replacement. Many Sage 200 reports remain useful for operational tasks and continue to be used. Power BI handles the dashboards, the cross-source reporting, the multi-company consolidation, and the analytical work that Sage 200 reports do not cover. Most clients run both indefinitely. Some specific Sage 200 reports get retired over time as Power BI versions prove themselves; others stay because they are well-suited to their purpose.

You can migrate from Power BI Report Server to the cloud service later if your requirements change, and this is a common trajectory as data residency requirements evolve or are re-evaluated. Reports built for Report Server generally move to the cloud service with limited rework, though features specific to Report Server's older release cadence should be checked for compatibility.

You can run Power BI Report Server and the cloud service side by side, and this is common for organisations with mixed requirements - some reports that must stay on-premises for regulatory reasons, and others that can benefit from the cloud service's fuller feature set. Managing two platforms does add administrative overhead, which is worth weighing against the benefit of splitting content this way.

Yes — you can run the cost review yourselves, in principle. The whitepaper covers the methodology. The tooling is in the Microsoft admin portal. The five overspending patterns are recognisable once you know what to look for. The reason most organisations engage us anyway is that an external review surfaces patterns that internal teams miss because they are too close to the existing setup, and an external recommendation is easier to act on than an internal one because it is not entangled with last year's budget decisions.

Yes — you can start small and expand, and this is often the right approach. Many BC clients start with one or two priority dashboards (financial reporting and sales analytics are common starters) and extend from there as the foundations prove themselves. The architecture supports this incremental approach: the data layer is built once and serves many dashboards over time. The first eight-to-twelve weeks deliver the foundations and the first set of dashboards. Subsequent extensions are quicker because the foundations are in place.

Yes — you can start with a smaller engagement. Many Sage 200 clients start with a four-week Establish phase, which produces a written architecture and engagement plan with cost and timeline before any commitment to the build. The Establish phase is fixed price and produces value on its own (the architecture document is yours regardless of whether you continue with the build). This is the lowest-risk way to start and is the most common entry point for new clients.

Yes, through sensitivity label enforcement or through tenant-level export settings, both of which can restrict or block export for specified content or user groups. This is a common requirement for organisations with genuinely sensitive financial or personal data in their reports.

Yes — you can use multiple Business Central reporting tools at once, and most BC organisations do. The mix typically looks like: Native for documents, Jet or Power BI for finance, Power BI on Fabric for cross-source analytics. The mistake is using two tools for the same use case. The discipline is using each tool for what it does best, with clear ownership and clear retirement plans for tools that no longer earn their place.

Yes — you can use the Power BI UI/UX checklist as a template for your own reviews. The deck is the full version. If you want it in a Word or Excel format you can adapt for internal use, ask and we will share it. We only ask that you keep the credit visible if you publish a derivative externally.

Yes — migrating from Tableau, Qlik, or another BI tool to Power BI is standard work for us. We regularly migrate clients from Tableau, Qlik, Cognos, SSRS, and Excel-based reporting onto Power BI. The migration approach depends on the complexity of the current estate, the quality of the underlying data, and the number of reports in scope. We always recommend a proper semantic model rebuild rather than a like-for-like migration, because the opportunity to improve governance is best taken at migration time.

Yes — Microsoft did raise Power BI Pro pricing in April 2025. Power BI Pro went from £8 to £11 per user per month in April 2025. The increase was the first significant Pro price rise in years. If you are working from quotes or budgets prepared before April 2025, the per-user numbers will be wrong. PPU stayed at £19. Fabric capacity pricing was not changed at the same time. The Pro increase shifted the maths on the F64 viewer-licensing crossover, making higher capacities relatively more attractive than they were.

Whether app viewers need a Power BI Pro licence depends on the workspace's capacity licensing. Content in a workspace backed by Premium or Fabric capacity can generally be viewed with a free Power BI licence; content in a Pro-only workspace requires viewers to have Pro licences themselves. This licensing distinction is worth confirming during planning, since it materially affects rollout cost for a wide audience.

The core DAX and modelling skills are the same regardless of department, but the practical examples and the specific reports used in training differ significantly, and should reflect what each team will actually be building and using day to day rather than a one-size-fits-all curriculum.

No — we do not have to leave BC to get good reporting. Power BI works alongside BC, not instead of it. BC continues to do what it does well (transactional ERP, financial integrity, operational workflows). Power BI handles the analytical layer on top: dashboards, cross-source reporting, self-service analytics, advanced analytics. The two complement each other. Most BC users we work with end up with both running together permanently. Power BI is not a replacement for BC; it is the analytical layer BC was never designed to provide.

Both Microsoft Fabric and Power BI alone can work. Power BI alone (Pro or PPU) is usually fine for simpler BC-only reporting. Power BI on Fabric becomes the right answer when you have multiple data sources, larger data volumes, AI ambitions, or you want a single platform for all analytical workloads. Most mid-market BC users we work with end up on Fabric because the integration tax of running multiple BI tools usually outweighs the Fabric capacity cost. The True Cost FAQ covers the licensing maths in detail.

You do not necessarily need your Sage 200 partner involved. Hopton can work directly with the client, accessing Sage 200 data through standard interfaces. The engagement runs more smoothly when the Sage 200 partner is informed and supportive, but it is not a hard requirement. We have run Sage 200 engagements with the partner involved, with the partner informed but not active, and without the partner in the loop. The right pattern depends on the client relationship with the partner, not on the technical work.

No — you do not need to already have Power BI before working with us. Many clients come to us before they have invested in tooling. Part of the Establish phase is assessing your current infrastructure and recommending the right platform for your needs and budget. If Power BI is the right fit, we will build it properly from the start. If a different Microsoft platform suits you better, we will say so.

You do not strictly need formal Power BI training - some people will figure out the basics themselves - but that usually produces inconsistent practice across an organisation: different people building reports different ways, some using DAX correctly and others working around it with overly complex Power Query steps, and no shared understanding of what "good" looks like. Structured training gets everyone to a consistent, correct baseline faster than informal self-teaching.

We have working relationships with the BC partner channel and we know the Jet team. We do not resell Jet or take referral fees on it. Our recommendation is based on what fits your situation, not on commercial relationships.

Yes — we do train teams on the Power BI UI/UX checklist. We run training sessions for internal BI teams, usually as a half-day workshop using one of your own reports as the worked example. People learn the list faster on real content than on slides. We can also run periodic refresher sessions as new team members join. Get in touch if you want to discuss.

Fabric capacity does not replace the need for Power BI Pro licences below F64. On any F-SKU below F64, every user who creates or views Power BI content still needs a Pro or PPU licence. F64 and above include free viewing for any user, so viewers no longer need their own Pro licence. Authors always need Pro regardless of capacity tier. This is the most commonly missed cost pattern. Buying F8 thinking it covers everything and then discovering 200 users still need Pro at £11 each is a £2,200 monthly surprise.

Hopton delivers Power BI training both as a standalone service and within projects. Training is built into every implementation engagement as standard, and we also deliver standalone training programmes for organisations that already have Power BI in place but have never had structured training, or that are onboarding a new cohort of users.

Designing the app structure is part of our standard Build phase design work, alongside workspace structure, security, and dashboard design, rather than treated as an afterthought once dashboards already exist. Deciding early who the actual audiences are and what each should see shapes both the workspace and the eventual app structure.

Hopton implements and supports Power BI Report Server deployments where a client has a genuine data residency or regulatory driver for it. We are honest that this is a smaller part of our practice than cloud Power BI and Fabric work, reflecting how much less common a genuine on-premises requirement is across our client base, but we do deliver it properly where it is the right answer.

Security and governance configuration is built into our standard Analytics Acceleration Programme rather than sold as a bolt-on. Security design happens during the Establish phase alongside architecture and dashboard planning, because retrofitting proper RLS and permissions after dashboards are already built and in daily use is materially more disruptive than designing it in from the outset.

Yes — Hopton does run its own FP&A on Power BI. Our FP&A reporting (group P&L, cash flow, working capital, headcount, KPIs) runs on Power BI sitting on Microsoft Fabric, fed from Business Central. The dashboards we use internally are built on the same patterns we deliver to clients. We are happy to walk prospective clients through our internal FP&A estate as part of the early conversation.

Honestly, no — Hopton does not specialise in Salesforce. Our heritage is Microsoft and we have deeper expertise in Dynamics 365 Sales than in Salesforce. We do work on Power BI on Salesforce and the architectural patterns transfer cleanly: the analytical layer is the same regardless of the source CRM. Where the engagement is heavily Salesforce-specific (complex Apex customisation, deep Salesforce admin work), we coordinate with a specialist Salesforce partner rather than overclaiming. Most mid-market CRM analytics work on Power BI does not require deep Salesforce specialism.

Hopton trains your team to be self-sufficient rather than dependent on us; the explicit goal is self-sufficiency. We would rather train your team well enough that they can extend and maintain their own reporting than keep you dependent on us for routine work. Continuity support exists for genuinely complex extensions and strategic development, not for tasks your own trained team should be able to handle.

Yes — Hopton does work with Sage 50, Sage Intacct, or other Sage products. Sage 50 is generally simpler to integrate (smaller scale, simpler data model). Sage Intacct is the cloud-first Sage product, cleanly API-driven, and integrates well with Fabric. Sage 1000 and other older Sage products work too, with extraction patterns adapted to the source system. Sage 200 is the most common Sage product in our work, but we have engagements across the Sage range. Email us if you are on a Sage product not specifically covered here and we will discuss the patterns that apply.

Yes — Hopton works with both Salesforce and Dynamics, with depth varying by platform. Dynamics 365 Sales is closer to our Microsoft heritage and we work on it regularly. Salesforce we work on where the analytical workstream is the focus and the Salesforce admin work is handled by an existing Salesforce partner or in-house team. The analytical patterns transfer between platforms. The architecture, the modelling, and the dashboards look similar regardless of the source CRM. The platform-specific work concentrates in the extraction and the data hygiene.

No — Looker does not only work with Google Cloud, but it works best there. Looker connects to BigQuery, Snowflake, Redshift, Postgres, MySQL, and many other databases. The deepest integration is with BigQuery, which is unsurprising given Looker is owned by Google. If your data warehouse is BigQuery, Looker is the most natural fit. If your data warehouse is on a different platform, Looker still works, but the integration advantages diminish.

No — Power BI Report Server does not get the same features as the cloud service, and the gap has widened over time. Power BI Report Server receives a subset of Power BI Desktop's features on a slower cadence (roughly every few months rather than continuous updates), and cloud-exclusive capabilities - Copilot, Fabric integration, real-time dashboards from streaming sources - are not available on Report Server at all.

Yes — Power BI has an equivalent semantic layer, but it works differently. Power BI's semantic models (formerly called datasets) sit at the workspace level and are built using the Tabular Editor or in Power BI Desktop. They support DAX measures, RLS, and centrally certified definitions. The certification mechanism is the closest equivalent to LookML's enforced consistency. The difference is cultural: LookML enforces engineering discipline by default, Power BI semantic models support engineering discipline if you choose to apply it. A well-governed Power BI estate matches what LookML enforces. A casually-governed Power BI estate does not.

No — Power BI does not only work with Microsoft data sources; it is a similar story. Power BI connects to almost everything, including Snowflake, BigQuery, Databricks, Redshift, Salesforce, and most enterprise data sources. The deepest integration is with the Microsoft stack: Azure SQL, Fabric, Dataverse, Dynamics 365. If your data and applications are Microsoft-centric, Power BI is the most natural fit. The connector library is broad enough that Power BI works with non-Microsoft sources too.

Power BI usually does not replace your budgeting and forecasting tool. Specialist budgeting and forecasting tools (Anaplan, Vena, AimPlan, Adaptive Insights, Workday Adaptive, Oracle EPM) handle the planning workflow itself: scenario building, driver-based modelling, approval cycles, model maintenance. Power BI handles the analytical and reporting layer on top of the planning data. The two work together. Many of our clients run their planning in a dedicated tool and their reporting in Power BI, with the two integrated through the lakehouse. For smaller firms whose planning happens in Excel, Power BI is the upgrade for both planning storage and reporting in one step.

Power BI does not support migrating away from Looker natively. Power BI has no built-in Looker or LookML importer, so there is no automatic conversion path between the two platforms. LookML's modelling layer and Power BI's semantic model are structured differently, which means metric definitions, joins, and dashboards have to be rebuilt rather than migrated file-for-file. That structural gap is why a Looker-to-Power BI move is best treated as a short project rather than a one-off export, even for teams comfortable with both tools.

Yes, through Azure Active Directory (Microsoft Entra ID), which handles authentication for Power BI as it does for the rest of Microsoft 365. Multi-factor authentication and conditional access policies configured at the Entra ID level apply to Power BI access as they do to other Microsoft 365 services.

RLS works largely the same way for Power BI reports built on top of Fabric data sources - the underlying mechanism is the same - but with Fabric, security can also be enforced further upstream at the data source (lakehouse or warehouse) level through Fabric's own security model, giving you a choice of where to enforce restrictions. We generally recommend enforcing security as close to the source as practical, with RLS in the semantic model as an additional, consistent layer.

The app mechanism itself works the same way regardless of whether the underlying workspace sits on Power BI Premium or Fabric capacity. What does change is the scale of content and audience complexity Fabric-based estates tend to reach, which makes deliberate app and audience planning even more important as the estate grows.

A sensitivity label can be both a visual tag and an enforced restriction. A sensitivity label can be purely informational, or it can be configured to enforce real restrictions - blocking export to Excel or PDF for highly confidential content, for example. Whether to enforce restrictions or use labels informationally is a deliberate governance decision, not a default setting.

Choosing Report Server does effectively mean giving up Power BI's AI and Copilot capabilities for content hosted on Report Server itself. Copilot for Power BI and other AI-augmented features are cloud-native and are not available on the on-premises platform. This is one of the most significant trade-offs to weigh against a data residency requirement, and it is one we discuss explicitly before recommending Report Server.

It does not directly matter which Business Central implementation partner you used. Hopton works alongside BC partners rather than replacing them. We do not need access to BC's transactional configuration. We do need access to BC data through standard APIs or, for on-premises, database access. Most engagements run smoothly when the BC partner is informed and supportive, but the analytics workstream is independent of the BC partner relationship. We have several engagements where we work with the BC partner in parallel and several where we work directly with the client without the partner involved.

Moving to Power BI Report Server generally does not reduce your overall IT overhead compared to the cloud service - it increases it, since you take on infrastructure management, patching, and capacity planning that Microsoft handles automatically in the cloud service. The trade-off is deliberate: more operational overhead in exchange for full data residency control. We are candid with clients that this is rarely a cost-saving move relative to the cloud service.

No — publishing an app does not duplicate the underlying reports. An app references the same underlying datasets and reports as the source workspace; publishing an app does not create a separate copy of the data or the report definitions. When the underlying workspace content is updated and the app is republished, app users see the updated version, not a stale copy.

Yes, RLS defined in the underlying semantic model continues to apply exactly as it does for any other consumption method. An app is a distribution and navigation layer; it does not bypass or replace the security already built into the semantic model beneath it.

The BC-to-Fabric lakehouse architecture applies to both BC SaaS and BC on-premises. The architecture is the same: extract data from BC into a lakehouse, build certified models, expose Power BI reports. The extraction mechanism differs (Lakehouse Connector and BC APIs for SaaS, direct database access or scheduled extracts for on-premises). The outcome is the same. Most new BC implementations are SaaS, but Hopton has experience with both. The whitepaper and the BC Implementation FAQ cover the technical detail.

This applies mostly to BC SaaS, but the patterns work for BC on-premises with adjustments. The biggest differences are around extraction methods (BC SaaS uses APIs and the lakehouse connector; BC on-premises uses direct database access or SSIS) and identity (BC SaaS integrates natively with Entra ID; on-premises requires more setup). The architecture pattern downstream of the extraction layer is the same. We work with both and the whitepaper covers both.

Yes — it does work for project-based businesses on Sage 200. Project-based businesses (professional services, construction, engineering) need project profitability, work-in-progress, cost recovery, and project-level cash flow visibility. The Sage 200 data plus project management tooling (Sage 200 Project Accounting, Microsoft Project, custom systems) feeds the analytics layer. Project P&L, project pipeline, and consolidated multi-project views are common dashboards. Project businesses often find this analytics extension produces meaningful commercial improvement because project visibility in the source systems is usually limited.

Properly structured training covers both, because most real-world reporting problems involve shaping and cleaning data in Power Query before any DAX measure is written. Training that only covers visual report building without the underlying data preparation skills leaves report builders unable to extend or troubleshoot their own models.

Training matters for both people building reports and people just viewing them, though the depth differs considerably. Report viewers benefit from a short session on navigating filters, drill-through, and export options so they get real value from what has been built for them. Report builders need much deeper training in data modelling, DAX, and Power Query.

Using apps reinforces the same discipline around certified or promoted datasets rather than changing it. Certifying the datasets that feed your app's reports gives app consumers (and anyone building further reports against those datasets) confidence that what they are seeing is the trusted, governed version, which matters even more once content is being distributed to a wide, less technical audience.

Microsoft has not committed to a single direction for BC reporting, and that is a feature, not a bug. Microsoft continues to invest in Native (RDLC, Word layouts) for operational reporting and in Power BI for analytics. The architectural direction is clear: operational stays in BC, analytical moves to Power BI and Fabric. Within that, there is room for finance-specific tools like Jet to keep their place.

To avoid cognitive overload on a Power BI page, aim for three to five visuals per page, not nine to twelve. Make one of them clearly the primary insight and let the others support it. Use white space, not borders, to separate areas. Strip every visual that does not earn its place. Cognitive overload comes from too many things competing for attention, and the fix is almost always to remove rather than rearrange.

To choose a Power BI consultancy, look past the dashboard gallery to the engineering and the operating model. Ask about data modelling (star schema), DAX optimisation, deployment pipelines, performance tuning, and governed self-service including certified datasets and row-level security. Confirm who actually does the delivery, and ask them to define success in business outcomes — faster close, fewer reporting disputes, better decisions — rather than dashboard aesthetics. Firms that answer with specifics and can show their delivery method are the ones worth shortlisting.

Download a theme as a JSON file, then in Power BI Desktop go to View, then Themes, then Browse for themes, and select the file you downloaded. The theme applies to the whole report instantly, recolouring visuals, fonts, and backgrounds to match. Hopton publishes a set of free Power BI themes for exactly this purpose; no setup or add-in is required beyond Power BI Desktop itself.

To know if a Power BI report is performant enough, open the report cold from the Power BI Service. If the first page loads in under five seconds, you are in good shape. Five to ten seconds is acceptable but worth optimising. Over ten seconds is a problem and will affect adoption. Performance is part of the user experience, not separate from it. Slow reports get used less, regardless of how good the design is.

Three rules make Power BI reports accessible. Never use colour as the only signal of meaning. Always check that contrast is sufficient, particularly for grey text on light backgrounds. Test the report at different zoom levels and on different screens. Power BI has accessibility tooling built in, and the checklist has a full category dedicated to accessibility. Most accessibility issues are easy to fix once seen, and invisible until pointed out.

You do not score a report against the Power BI UI/UX checklist - we do not score. Each check is binary: pass or needs work. The output is a list of issues, prioritised, with screenshots. Scoring tempts teams to chase a number rather than fix problems. Issues are concrete, scores are not. If you must score for governance reasons, count the items needing work and track that downward over time.

Email hello@hoptonanalytics.com with a brief description of your CRM (Salesforce or Dynamics), your sales team shape, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a three to four week Establish phase that produces an architecture and a priority delivery plan.

Email hello@hoptonanalytics.com with a brief description of your finance team shape, your current FP&A cycle, your main systems, and what you are trying to improve. The first conversation is exploratory and free. If there is a fit, we propose a four-week FP&A Establish phase that produces the architecture and the priority delivery plan.

On white-label and embedded customisation, Power BI and Looker differ in that Looker is more flexible. Looker embedded looks more like part of the host application and less like a BI tool. The styling, the colour scheme, the navigation can all be controlled. Power BI Embedded is improving on these dimensions but still feels like Power BI by default. Where the analytics needs to feel native to a customer-facing product, Looker is usually the better answer.

They work together as two ends of the same pipe rather than as rivals. Power BI is the reporting layer that shows what is happening across the business; Power Apps is the action layer that lets someone capture a decision or update a record. The useful pattern is to connect them: a Power App can be embedded directly inside a Power BI report as a visual, so the moment a user spots an at-risk account or an exception, they can act on it in the same place they saw it, without switching systems or raising a separate request.

Word layouts are easier to maintain than RDLC for simple documents. Most modern BC users build customer-facing documents in Word layouts where possible and reserve RDLC for documents needing the additional control. The skill-find for Word layouts is also broader than for RDLC, which matters in mid-market organisations without dedicated BC developers.

The underlying RLS mechanism in the semantic model works the same way, but tenant-level governance features available in the cloud admin portal - centralised usage monitoring through Purview audit logs, some sharing and certification features - are more limited or entirely unavailable on Report Server. Governance has to be designed around what the on-premises platform actually supports, not assumed to match the cloud experience.

Apply sensitivity labels at the dataset level for content that needs them, propagate to derived content automatically. Microsoft Purview is the underlying tool. The discipline is deciding which datasets warrant labels and applying them consistently. The mistake is applying labels inconsistently or not at all, then hoping nothing sensitive ever flows into the wrong report. Labels are a one-time setup with ongoing operational benefit.

Unused Pro licences accumulate slowly, over time. Someone gets a licence for a project that ends. They move to a different role and stop using Power BI. They leave the organisation but the licence persists. A 200-staff organisation often has 30 to 50 inactive Pro licences without anyone noticing. At £11 per user per month, that is £3,300 to £5,500 per year of pure waste. The fix is a quarterly review of licence assignments against active usage. Microsoft provides usage reports for this. Use them.

We control external sharing of Power BI reports outside our organisation through tenant-level external sharing settings in the admin portal, which can be disabled entirely, restricted to specific domains, or left open depending on your organisation's genuine need to share with external parties such as clients or auditors. Most mid-market organisations benefit from restricting this by default and enabling it selectively where there is a real business case.

We control who can access a published Power BI app through defined audiences within the app, each of which can be assigned specific content and specific security groups or individuals, all managed from within the app publishing settings rather than through workspace roles. This lets a single app serve genuinely different audiences with different visible content from one underlying workspace.

We decide whether Report Server or the cloud service is right for you by identifying whether you have a genuine, specific requirement - regulatory, contractual, or security-driven - that rules out the cloud service, rather than assuming on-premises is inherently safer or more controlled by default. In our experience, most mid-market businesses do not have such a requirement and are better served by the cloud service's faster feature pace and lower operational overhead.

We decide who needs deep Power BI training versus a lighter overview by mapping out who will actually build and maintain reports versus who will only consume them, and training accordingly. We usually see this settle at a small group of two to five power users or analysts needing deep training, with a much wider group needing only consumer-level training.

We evaluate a consultancy's pricing transparency by asking specific questions and listening to the answers. A transparent pricing model has clear day rates, clear scope, clear assumptions, and clear handling of changes. An opaque pricing model has vague hourly rates, broad scope statements, hidden assumptions about your team's involvement, and unclear handling of changes. Ask: what is the day rate by grade; what is included in the fixed price; what assumptions about our involvement are baked in; what happens if scope changes. The clarity of the answers is itself the signal.

Email hello@hoptonanalytics.com describing your current Power BI setup and any specific concerns. We regularly review existing estates - built by us or by others - and can scope a focused security and governance assessment independent of any wider engagement.

Email hello@hoptonanalytics.com describing your current workspace and app setup, or the lack of one, and who your different report audiences actually are. We will review your current structure and recommend an audience and navigation design as part of scoping, whether as a standalone piece of work or part of a wider engagement.

Email hello@hoptonanalytics.com describing your specific data residency or regulatory driver and your current reporting setup. We will give an honest assessment of whether Report Server is genuinely the right fit before recommending it, rather than defaulting to it just because it has been asked for.

Email hello@hoptonanalytics.com describing your current Power BI setup (or lack of one), your team size, and roughly how many people need report builder versus consumer-level training. We will scope a training programme, whether standalone or as part of a wider implementation.

Power BI reports that span Business Central and other systems are almost always best handled with Power BI on Fabric. Native cannot do it. Jet struggles beyond BC. Power BI direct gets there but the architecture stops scaling. Fabric is built for multi-source analytics and BC's data sits comfortably alongside Shopify, Xero, CRM and others. If you have any meaningful multi-source need, the long-term answer is Fabric.

We handle Power BI version control when multiple people update a workspace before an app republish through the same workspace-level version history and review discipline that should already govern production content, combined with a clear internal process for who reviews and triggers the app republish. The app republish step is a natural checkpoint to enforce this review, and we build that checkpoint deliberately into governance design.

Three questions decide which Business Central reporting tool you need. Who is the report for? What data sources does it touch? What is the ambition (operational, self-service analytics, advanced modelling)? Match each report to those answers, and the right tool surfaces. The deck has a full decision framework. Most BC organisations do this assessment once and find they are using the wrong tool for at least one use case.

F8 is the most common production starting point for mid-market workloads. F2 and F4 are for trials and very small production environments. F16 makes sense when you have multiple departments running concurrent demanding workloads. The honest answer is to size from real data: run a representative workload on a trial capacity for two to four weeks and monitor utilisation. Microsoft provides a Capacity Metrics app. Guessing produces over- or under-provisioning, both expensive in different ways.

We monitor who is actually accessing what in Power BI through Power BI's built-in usage metrics reports, and more comprehensively through the Microsoft Purview audit log, which records detailed activity across the tenant - who viewed, edited, or shared specific content and when. We set this up as standard on governance-focused engagements, since usage data is also valuable for licensing and content rationalisation decisions.

To run a competitive consultancy selection process well, brief all firms identically. Set clear evaluation criteria in advance and score against them. Make the same time available to each firm for discovery questions. Allow each firm to interview your team to ground their proposal. Compare the proposals against the criteria, not against each other in isolation. Run reference calls before final selection, not after. Negotiate contract terms with the preferred firm, not all of them simultaneously. The discipline of a clean competitive process produces better outcomes than relying on instinct or relationships alone.

To shortlist Power BI consultancies to evaluate, aim for three to five firms as the right shortlist size. Fewer means insufficient comparison; more means too much evaluation effort for the buyer. Sources for the shortlist: the Microsoft Partner Network listings (filtered by Solutions Partner for Data and AI), recommendations from peers and your existing Microsoft account team, the FAQ libraries and content of credible firms (which signals depth of expertise), and named referrals from other consultancies you trust. Avoid shortlists driven by volume of marketing or by which firms appear most prominently in search results; both signal marketing investment more than capability.

We stop someone accidentally deleting or overwriting a critical Power BI report through a combination of workspace role restrictions (limiting who has Contributor or Admin rights on production workspaces), version history (Power BI retains previous versions of reports, allowing rollback), and, for the most critical content, a deployment pipeline process that requires review before changes reach production.

Microsoft Solutions Partner designations are listed on the partner's Microsoft profile and can be verified through the official Microsoft Partner Network listing. Individual certifications can be verified through Microsoft Learn (each certified person has a verifiable transcript). Pyramid Analytics and other vendor certifications can usually be verified through the vendor's partner directory. Verification takes ten minutes and is worth doing for any serious engagement. A consultancy whose claimed credentials cannot be verified deserves a sceptical second look.

We decide what goes into an app versus what stays workspace-only by identifying which reports are genuinely finished, validated, and intended for a specific audience, versus which are still in development or intended only for the report-building team. We treat this as a deliberate curation decision during design, not an afterthought once reports happen to exist in a workspace.

We decide what level of security a given Power BI deployment actually needs by understanding what data is genuinely sensitive (financial detail, personal data, commercially confidential information), who legitimately needs to see what, and what the real consequence of over-exposure would be. This is a discovery conversation, not a checklist applied uniformly to every client.

We handle Business Central schema changes between versions carefully. BC's data structure can change meaningfully between versions, particularly during major Wave releases. Extraction patterns built against one version may need adjustment when the source upgrades. The lakehouse architecture protects you from this: changes are absorbed in the Bronze and Silver layers, with Gold staying stable. Reports continue to work. The maintenance work happens in the data layer, not in the report layer. This is one of the strongest arguments for the architecture.

We handle reforecasts mid-year by treating each forecast as a separate version in the Budget fact, tagged with the forecast date. Reports show the original budget, the latest forecast, and actuals against both. Comparison across forecasts (March forecast versus June forecast) surfaces how the leadership team's view of the year has evolved. For mid-market businesses with quarterly or rolling forecasts, this is usually the right pattern. The model preserves history rather than overwriting, which preserves the audit trail.

BC data gets into Fabric through BC's APIs, with the data landing in a lakehouse layer. Most projects use a Bronze, Silver, Gold pattern: raw API data into Bronze, cleaned and modelled in Silver, business-ready facts and dimensions in Gold. Power BI semantic models point at Gold. The architecture is more substantial than direct connection, but it scales and supports multi-source analytics cleanly.

BC's API and direct database access can struggle with heavy analytical queries, particularly across long history or large fact tables. The system is optimised for transactional behaviour, not analytical scans. For light to moderate analytics on recent data, BC direct queries work. For heavy analytics across years of history, the load on BC affects transactional users. The fix is to extract the data into a separate analytical layer (lakehouse or warehouse) and run analytics there, which is what Fabric provides.

Copilot fits with Dynamics 365 Sales analytics at two layers. Copilot inside Dynamics 365 Sales helps sales reps with summarisation, opportunity insights, and email drafting. Copilot in Power BI sits on top of the analytical layer and helps sales leadership query the data conversationally. Both run on Fabric capacity. The combination is genuinely useful when the underlying data is governed and the certified semantic model is in place. Without those foundations, both Copilots produce confident-sounding outputs that should not be trusted.

Hopton engages on BC analytics through a phased delivery. Most engagements start with a four-to-six week Establish phase: we audit your BC environment, agree the priority dashboards with your finance and operations leaders, design the architecture, and produce a written engagement plan with cost and timeline for the Build phase. Build is typically eight to twelve weeks for a production first release. Continuity is the optional ongoing engagement that maintains and extends the platform after launch. Most BC clients stay in Continuity because the analytics needs evolve with the business.

Hopton engages on BC implementations starting with a four-week scoping engagement that produces the architecture, the priority domain list, and the cost and timeline. From there, the build is typically eight to twelve weeks. Continuity is the optional ongoing engagement after launch. We work alongside existing BC partners (we do not displace them on the ERP side). Many of our BC clients come to us through their BC partner.

Hopton engages on BC reporting decisions in two ways. A reporting strategy engagement, two to three weeks at fixed price, covering audit and tool selection. We produce a written reporting strategy with tools, audiences, and reasoning. Or full delivery, where Power BI or Fabric is the right answer and we build it. We work alongside whatever else stays in the mix (Native, Jet) without trying to replace it.

Most clients start with a four-week FP&A scoping engagement: discovery of the current cycle, the priority reports, the source systems, and the architecture. The Build phase runs 6 to 10 weeks: the priority FP&A reports, the lakehouse foundations, the semantic models. Continuity is the optional ongoing engagement after launch. We work alongside the existing finance function rather than replacing it. The finance team continues to run the cycle; we deliver the analytical layer that makes the cycle faster and cleaner.

Most clients start with the Power BI Health Check, a two-week fixed-price engagement that audits your existing estate against the architecture standards in the whitepaper. Output is a written report with prioritised recommendations. From there, the work usually splits into modelling improvements, workspace restructure, and governance. The scope depends on what the Health Check surfaces.

A two to three week structured cost review covering all your Power BI and Fabric spend. Output is a written report with: current cost breakdown, sizing recommendations, identified overspending patterns, and a prioritised list of changes with the savings each one delivers. Most reviews surface double-digit-percentage savings without losing capability. Fixed price, fixed output, no obligation to use us for the implementation.

Most clients start with the Self-Service Readiness Assessment, a two-week fixed-price engagement that audits your existing setup against the five foundations. Output is a written report identifying which foundations are in place, which are missing, and a sequenced plan for closing the gaps. From there, the work splits into foundation work (certified models, governance, integration) and rollout work (training, audience tiering, change management).

Hopton's approach is Microsoft-first: we build on the Microsoft stack: Fabric, Power BI, the Lakehouse Connector, and Copilot. The advantage is no third-party dependency: you own the architecture and the platform sits on the same Microsoft stack as your other M365 investment. The disadvantage is more upfront work than a packaged solution like Cosmos. The trade-off favours Hopton's approach when you have multi-source needs or AI ambitions, and favours packaged tools when you have neither and want speed.

Looker is significantly more expensive at typical mid-market scales. Looker pricing is platform-based with per-user add-ons; mid-market deployments commonly run into multiple tens of thousands of pounds per year before user counts get large. Power BI Pro at £11 per user per month is far cheaper for the same audience. Even Power BI Premium or Fabric capacity at the F64 tier (around £6,400 per month) is usually less than a comparable Looker deployment. Looker's pricing reflects its positioning at the engineering-led, embedded-analytics, larger-enterprise end of the market.

Microsoft's Business Central analytics roadmap is increasingly Fabric-centric. The investment is going into Lakehouse Connector improvements, Fabric integration, and Copilot inside BC. If your strategy is BC plus Power BI on Fabric, the roadmap is in your favour. If your strategy depends on Native RDLC for analytics or on third-party tools that compete with Fabric, the roadmap is mostly orthogonal to your plans. The roadmap does not invalidate other approaches but it does signal where the integrated experience will be best.

Power BI connects to Sage 200 through one of three options. Direct database connection (for on-premises or partner-hosted Sage 200, where SQL Server access is available). Sage's web API (for cloud-hosted Sage 200, where direct database access is not). Scheduled exports into a staging area, then loaded into Fabric. Most engagements use the first or second option. The data lands in Fabric Bronze, gets cleaned and structured in Silver, and reaches Gold as business-ready facts and dimensions for Power BI semantic models.

Power BI builds a customer 360 view across CRM and ERP by integrating CRM and ERP data on a common Customer dimension. The CRM provides relationship, opportunity, and activity data. The ERP provides actual revenue, profitability, payment behaviour, and product mix. The Power BI customer 360 dashboard shows both views together: the relationship picture from CRM and the financial picture from ERP. For most mid-market businesses, this is the first time the sales leadership and the finance leadership are looking at the same customer view.

Power BI handles Salesforce custom objects and fields the same way as standard objects. The challenge in Salesforce is rarely the technical extraction; it is the proliferation of custom fields and objects accumulated over years. A typical mid-market Salesforce org has hundreds of custom fields, many of them unused or duplicated in purpose. Part of the early engagement work is identifying which custom fields are operationally meaningful versus which are legacy. Bringing every custom field into the analytical layer produces unusable reporting.

Power BI handles budget versus actual reporting through a Budget fact aligned to the same Account, Department, and Entity dimensions as the Actuals fact from the ERP. The model calculates variance (actual minus budget) and variance percentage. Reports show the P&L with budget, actual, and variance columns, with drill-throughs to the underlying transactions. The standardisation is what most businesses lack: budgets in Excel against actuals in the ERP, with the comparison done manually each month and reconciliation effort consuming finance team time. Encoding the comparison in Power BI makes it routine.

Power BI handles currency translation through the standard accounting conventions: P&L items at average rate, balance sheet items at closing rate, with the difference flowing to a currency translation reserve. The Power BI model encodes the translation logic and the dashboard shows entities in their reporting currency, the group consolidated currency, and the translation impact. For groups with significant overseas operations, currency translation can be a material driver of reported results, and the dashboard makes the impact transparent rather than hiding it in the consolidation.

Power BI handles intercompany eliminations in consolidation through a model that encodes the elimination rules: matching intercompany transactions across entities and netting them off in the consolidated view. The complexity is identifying intercompany transactions reliably, which depends on the source data being tagged appropriately. Some ERPs handle this well (BC, NetSuite, SAP) and some require additional effort. Where the source data is weak, the Silver layer in the lakehouse is where the matching gets done. Once encoded, eliminations run automatically each month.

Power BI handles multi-entity consolidation through the standard consolidation pattern: each entity's actuals and budgets flow into the model with appropriate eliminations (intercompany trading, intercompany debt). Currency translation is applied where entities report in different currencies. Reports show entity-level detail and consolidated views from the same model. For mid-market groups with several legal entities, this is usually one of the highest-stakes uses of Power BI because the consolidated reporting is the basis of the board pack and the lender reporting.

Power BI itself does not automatically apply GDPR-specific protections; it is a reporting tool operating on data that may include personal data, and GDPR compliance depends on how that data is sourced, secured, and governed across your wider estate, not on a Power BI setting alone. RLS, sensitivity labels, and proper access control all contribute to compliance, but the underlying data governance discipline matters more than any single Power BI feature.

Power BI handles sales cycle analytics through cycle time measures: average days from lead to opportunity, opportunity to qualified, qualified to closed-won. The reports show cycle time by deal type, by rep, and by customer segment, with trends over time. Lengthening cycle times are usually an early warning of deal quality issues or pipeline weakness. The analysis depends on the historical stage timestamps, which both Salesforce and Dynamics capture by default.

Power BI handles variance commentary and explanation beyond just the numbers - the variance numbers are the easy part. The harder part is the commentary explaining why the variances occurred. Power BI does not write commentary, but it can structure the data to make commentary easier: variances ranked by size, drill-throughs to the specific transactions driving variance, and historical context (is this variance pattern recurring or new). Some clients use Copilot in Power BI to draft commentary on the largest variances, with the finance team reviewing and refining.

Power BI integrates with Dynamics 365 Sales through Dataverse, the underlying data platform. Dataverse exposes Dynamics data through native Power BI connectors and through Microsoft Fabric's direct integration. The Fabric route gives you the cleanest path: Dynamics data flows into OneLake automatically, with the Dataverse schema reflected as Delta tables, ready for Power BI semantic models. The integration is genuinely tighter than any other CRM-to-BI integration because both products are Microsoft.

Power BI integrates with HR systems through scheduled extraction from the HR system (Workday, Sage People, BambooHR, Personio, BrightHR, or similar) into the lakehouse. The Headcount fact captures position, individual, location, department, and start and end dates. Joining to the payroll or finance data gives the cost view. The integration is straightforward where the HR system has exportable data; for older or bespoke HR systems the extraction is more involved. The pattern is well-established.

Power BI integrates with Salesforce through scheduled extraction from the Salesforce APIs into the lakehouse. Salesforce has a mature API set (REST API, Bulk API, and increasingly the Data Cloud surface) that supports both standard objects (Account, Contact, Opportunity, Lead) and custom objects. The Power BI connector handles smaller volumes directly. For mid-market estates with significant data and a need for good performance, the right pattern is usually scheduled extraction into Microsoft Fabric, with Power BI semantic models on top.

Power BI has mobile apps for iOS and Android with offline support and push notifications. Reports designed for mobile (different layout from desktop) work well for users who travel or work in the field. Sales managers reviewing customer activity, operations leaders checking site performance, executives reviewing KPIs on the move. Mobile is increasingly the primary interface for senior users. The design discipline is to build mobile-first views deliberately rather than expecting desktop reports to work well on a small screen.

Power BI on BC compares favourably to using Excel and Power Query directly: Power Query in Excel works for small-scale, individual reporting. It does not scale to shared, certified, governed reporting across an organisation. Excel files become stale, definitions drift between users, and the same metric appears with different numbers in different files. Power BI on a certified semantic model produces one definition, current data, and consistent numbers across the user base. Excel remains useful for ad-hoc analysis and reconciliation; Power BI handles the recurring reporting that needs to be trustworthy across the business.

Power BI reports on sales pipeline through an Opportunity fact with stage, value, owner, and time tracking. The pipeline dashboard shows total pipeline value, pipeline by stage, weighted forecast (value times probability by stage), and movement against last week or last month. Drill-throughs show the opportunities behind every number. The work is in defining the stages consistently across the business and tracking opportunities through their stage transitions over time. The historical stage transition data is what enables forecast accuracy analytics later.

Power BI reports on sales rep activity through an Activity fact tagged to rep, account, and opportunity. The dashboard shows calls, emails, meetings, and demos by rep, with the link to outcomes. Activity-only dashboards are common but they have a problem: they reward reps for activity volume regardless of outcome quality. The right pattern is activity in context with outcomes (deals progressed, opportunities created, deals won), so the dashboard supports the right management conversation rather than rewarding the wrong behaviours.

Power BI reports productivity and people-cost ratios through common derivations including revenue per employee, gross profit per employee, people cost as a percentage of revenue, and ratios specific to the business model (in PS firms: utilisation and realisation; in retail: revenue per labour hour). The Power BI dashboard tracks these alongside budget and historical baselines. They are often the most useful productivity indicators for the leadership team because they connect the headcount investment to the financial output.

Power BI reporting often works well alongside your existing BC partner. Most BC partners are strong on the ERP side and lighter on analytics. We work alongside the existing partner rather than displacing them. The ERP work continues in their hands and the analytics work runs in parallel. We have several clients who come to us through their BC partner because the partner does not want to take on the analytics workstream themselves.

Power BI supports sales win/loss analysis through a structured Loss Reason dimension applied at deal close. Reports show win rates by deal type, customer segment, competitor, and rep. The most useful win/loss analytics is loss-reason-by-stage: where in the cycle are deals being lost, and to whom. Patterns surface that inform sales enablement, product positioning, and pricing. The data quality issue is usually that loss reasons are filled in inconsistently or skipped. The reporting can flag missing loss reasons to sales managers, which improves data quality over time.

Power BI tracks lock-up and working capital through a model that captures debtor days, creditor days, and inventory days (where relevant). The dashboard shows the working capital cycle in days, the trend, and the cash impact of changes. For mid-market businesses, every day of working capital improvement is meaningful cash. Surfacing the trend, with the underlying drivers, is one of the most actionable financial outputs Power BI produces. The data lives in the ERP. The integration is straightforward.

Data gets from BC into the lakehouse through three main mechanisms. The Lakehouse Connector (Microsoft's native option for BC SaaS to Fabric, with periodic full and incremental loads). Power Query refresh against BC APIs (for smaller volumes or specific entities). Custom extraction via BC's standard APIs or, for on-premises, direct database access. Most modern BC SaaS implementations use the Lakehouse Connector for the bulk of the data and supplement with Power Query for specific gaps.

Driver-based forecasting builds the forecast from operational drivers (sales volume, conversion rate, average price, headcount, productivity) rather than from financial line items directly. The drivers feed the forecast through documented logic. Power BI shows the drivers and the forecast outputs together, allowing the leadership team to see what assumptions are driving the numbers. The model itself usually lives in the planning tool; Power BI presents it. The benefit is that the conversation moves from 'what is the forecast' to 'what assumptions are we making', which is a more useful conversation.

Multi-company consolidation works cleanly, and it is one of the strongest reasons to move analytics off Sage 200. Multiple Sage 200 companies feed into the same data layer in Fabric, with consolidation logic in Silver and Gold. The consolidated view shows the group P&L, balance sheet, and operational metrics across all entities, with the ability to drill back into specific companies. Multi-company is awkward in Sage 200's built-in reporting. It is straightforward in Power BI on Fabric.

The Business Value Question applies to self-service authors the same way it applies to the central team: self-service authors building content for an audience need the same discipline - name the decision, name the owner, name the action. Without it, self-service produces interesting reports that change nothing. The BVQ does not have to be heavy for self-service. A short version asking the four key questions is enough. The discipline is the value, not the document length.

The Fabric-capacity-without-Pro-licence overspend happens when an organisation buys Fabric F8 expecting it to cover everything. They then discover that every author and every viewer below F64 still needs a Pro licence at £11 per month each. Their actual monthly cost is £1,050 for the capacity plus another £1,500 to £2,500 in Pro licences nobody planned for. The fix is to model the full licensing cost before buying. Decide whether to size up to F64 or stay below and budget for per-user licences.

Power BI has a gentler entry curve and a steeper advanced curve. A business user can be productive in Power BI within days; mastering DAX and the deeper architecture takes years. Looker has a steeper entry curve (you need SQL and LookML) and a flatter advanced curve once the foundations are in place. The right comparison depends on who is going to use the tool. For business users, Power BI's entry curve matters most. For data engineers, Looker's flatter advanced curve matters most.

Both vendors price embedded analytics differently from internal use, so the licensing for embedded compares on that basis. Looker pricing for embedded is more granular and works better for SaaS applications with many end users. Power BI Embedded uses Premium capacity (or Fabric) which can be efficient at scale but expensive for low-volume embedding. The right answer depends on your end-user volume and the unit economics of your SaaS product. Both vendors quote on a case-by-case basis for embedded scenarios; published list prices are not the right starting point.

The Power BI UI/UX checklist is one of the working standards we apply on every Hopton delivery, fitting into the wider Hopton Analytics Acceleration Programme. It runs at three points in our build process: design, review and refine. Clients on the AAP get the checklist applied to every report we ship, by default. The same standards apply to your reports as to the ones we build for our own demonstrations.

Training fits into a wider Power BI or Fabric implementation project as a defined phase, not an afterthought. We build structured training into the Enable stage of every implementation, timed close to go-live so the concepts taught are immediately reinforced by using the actual reports the organisation will rely on day to day.

Sector experience is more important than buyers usually realise. Sector experience translates directly into faster discovery, better requirement understanding, and architectural patterns that work for the specific data shape your business uses. A consultancy that has done five retail engagements understands retail data; one that has done none will spend the first half of the engagement learning what your business actually does. Sector experience is one of the strongest predictors of engagement success and is worth paying a premium for, where the premium exists.

Decision Adoption Rate is measured through periodic sampling. Every quarter, take a sample of the recommendations from BI content over the previous period, and check whether action followed. Action means: the recommendation was acted on (yes or no). The percentage is the rate. The mechanism is light: an analyst spends a day per quarter walking through a sample with the relevant business owners. The number itself is less important than the trend over time.

Power BI Report Server differs from the regular Power BI service in where content lives and how it is accessed. Power BI Service is a Microsoft-hosted cloud platform with continuous feature releases and cloud-native capabilities like Copilot integration. Power BI Report Server is self-hosted, updated on a much slower, more deliberate release cycle, and lacks many of the newer cloud-only features, in exchange for keeping data entirely within your own infrastructure.

Power BI Report Server is licensed through Power BI Premium (per capacity) licensing or through SQL Server Enterprise Edition with Software Assurance, rather than the per-user licensing model used for the cloud service. This licensing structure should be confirmed directly with Microsoft or your licensing partner, since specific terms and eligibility can change.

RLS is configured through roles defined in the semantic model, each with a DAX filter expression (for example, restricting a sales table to rows where region equals the current user's assigned region), and then mapping specific users or Azure Active Directory groups to those roles in the Power BI service.

A workspace is where content is built, tested, and collaborated on; it is inherently a working environment and usually includes draft or in-progress reports alongside finished ones. An app is a separate, read-focused distribution layer built from a workspace's content, letting you control precisely what a wider audience sees without exposing the workspace itself or requiring workspace-level roles.

FP&A reporting is high-stakes (the board pack, lender reporting, statutory reporting) and the data quality bar is higher. The numbers have to reconcile to the audited accounts, and the variance commentary has to stand up to scrutiny. The architecture is the same as for operational analytics; the testing and certification effort is more intensive. The Trust Storytelling Delivery Checklist applies to every FP&A output and the Business Value Question shapes which reports get built. Both are covered in our Data Governance FAQ.

The Hopton checklist differs from Microsoft's own Power BI design guidance in emphasis: Microsoft's guidance is mostly about what is possible. Our checklist is about what is sensible. The two are different. Microsoft will tell you how to use bookmarks, custom visuals or themes. The checklist tells you when to and when not to. It is opinionated where Microsoft is permissive, and that is where the value is.

Workflow integration is implemented with Power BI in Teams as the default surfacing approach: dashboards visible in the channels users already inhabit. Email subscriptions delivering the headline numbers without requiring navigation. Embedded analytics in the line-of-business application where decisions get made. Mobile views for users who work away from a desk. Each integration point reduces the friction between question and answer. The aim is BI that comes to the user, not BI that requires the user to come to it.

A BC on Power BI implementation takes eight to twelve weeks for a production-ready first release with a single BC source and the priority reporting domains covered. Multi-source implementations or unusual data volumes extend the timeline. The eight-to-twelve week figure assumes a focused engagement with prioritised reporting needs and a working Microsoft estate. Stretched implementations (multiple competing priorities, scope creep, parallel workstreams) take longer.

A Business Central on Power BI implementation takes eight to twelve weeks for a production-ready first release with the priority dashboards covered. Faster if BC is straightforward and the priorities are clear. Slower if multiple BC companies need consolidating, non-BC sources need integrating, or governance overhead is heavy. The eight-to-twelve week range covers most mid-market BC implementations. Larger or more complex environments take longer; smaller and tidier ones can be quicker.

A CRM Power BI rollout takes six to ten weeks for the priority pipeline and rep performance dashboards. Three to six months for a full estate including customer 360, win/loss analysis, and the integrated revenue forecasting model. The pipeline dashboard goes live first because it is the one the sales leadership reviews weekly. The customer 360 work usually requires the ERP integration and is the longer thread.

A governed Power BI environment - with a proper semantic model, certified dashboards, row-level security, and adoption support - typically takes eight to twelve weeks in the Build phase, preceded by a four-week Establish phase. Simpler scopes can be faster; more complex data environments take longer. We scope precisely before committing to a timeline.

A Sage 200 Power BI implementation takes eight to twelve weeks for a production-ready first release. Faster if Sage 200 is straightforward (single company, clean data, focused priorities). Slower if multiple companies need consolidating, additional sources need integrating, or data quality work is significant. Most mid-market Sage 200 engagements come in within the eight-to-twelve week range. Larger or more complex environments take longer.

A successful self-service rollout typically takes nine to twelve months for the change to bed in. Shorter than that, the foundations are not in place. Longer than that, the momentum dissipates and you have to reset. The technology can be deployed in weeks. The behaviour change takes longer, because it depends on user habits, workflow integration, and trust. The framework covers both, because the technology piece without the behaviour piece is the standard failure pattern.

An FP&A Power BI rollout takes six to ten weeks for the priority reports if the underlying ERP and budget data are clean. Longer if data foundations need work first (multi-entity consolidation, currency translation, headcount system integration). The work often surfaces data quality issues that have been quietly tolerated for years. Solving them once is part of the value: the FP&A reporting becomes reliable, and the underlying data becomes useful for everything else.

A first review of a typical mid-market Power BI report takes ninety minutes to two hours. That assumes someone other than the builder is doing the review and is prepared to take notes as they go. A second-pass review after fixes lands at thirty to forty-five minutes. Reports with more than ten pages or unusual visual choices take longer. Reports that have already been reviewed once often need just a quick spot-check.

Report builder training typically takes meaningfully longer — spread across several sessions over two to four weeks, covering data modelling fundamentals, DAX from basic to intermediate level, Power Query transformations, and report design principles. Building genuine DAX competency takes sustained practice, not a single workshop.

Report consumer training typically takes a single focused session, usually two to three hours, covering what most report consumers need: navigating the specific dashboards built for them, using filters and slicers, and understanding what the numbers mean. Longer sessions are rarely necessary for this audience.

The procurement process should take two to six weeks for most mid-market engagements. Shorter than two weeks usually means you are not doing enough diligence; longer than six weeks usually means the procurement is becoming the engagement and the firm you are evaluating is losing momentum. Within that range, the right cadence is: initial conversation, scoping discussion, written proposal, references, contract negotiation, signing. Each phase should produce something concrete. If a phase drags without producing output, that is a signal.

The whitepaper covers more than fifty distinct BC extraction patterns across BC entities and use cases. Sales transactions, inventory ledger entries, item movements, customer aging, supplier aging, dimension breakdowns, multi-company consolidations, currency translations, year-end balances, period-over-period comparisons, and so on. The whitepaper documents the pattern, the entity involved, the typical destination shape, and the gotchas. Most BC implementations use a subset of these patterns, but the library covers most situations.

A report should use one font family, in three or four sizes. Three colours used meaningfully, plus a neutral palette for everything else. The discipline is harder than it sounds. Most over-coloured reports are not built that way deliberately. They drift there over time as different stakeholders ask for different visuals. The annual review is when you pull the colours back into line.

You should have one model per business domain, many reports per model. The pattern is one finance model serving all finance reports, one sales model serving all sales reports, one operations model, and so on. The temptation is one big model serving everything. That works at small scale and breaks at large. The temptation is also one model per report. That guarantees inconsistency. One per domain is the sweet spot for most mid-market organisations.

Neither extreme — one workspace for everything, or many — works well. A single workspace for an entire organisation makes permission management unwieldy and increases the blast radius of a mistake; a separate workspace per report fragments governance and makes reuse of shared datasets harder. We typically structure workspaces around business functions or departments, each with a clear owner and a defined publishing process.

Pausing capacity can save around 50 per cent of compute cost for workloads that only run during business hours. Reports refresh overnight and pipelines run on schedule, but the capacity does not need to be active for the rest of the time. Pausing overnight and at weekends typically halves the monthly bill where workloads allow. The automation is mature and straightforward. This is the single largest unrealised saving in most mid-market Fabric deployments.

Annual reservations save around 20 per cent off PAYG list prices. Three-year commitments through an Enterprise Agreement can save up to 41 per cent. If you are confident in your sizing and you plan to keep the capacity running, reservations are usually the right call. The risk is reserving capacity you do not need. The right approach is to size the capacity from real data first, run it on PAYG for a quarter to confirm, then reserve once the sizing is proven.

The cost of a Power BI consulting project depends on scope, but here is a real anchor. A standalone governed Power BI build, semantic model, certified dashboards and row-level security, typically runs eight to twelve weeks of delivery after a four-week Establish phase. Where clients want ongoing capability rather than a single project, our Analytics Acceleration Programme gives a clearer indicative cost: a Foundation-Focused tier for 25 to 100 people runs around £52.7k, Foundation-Standard for 100 to 500 people around £73.9k, and a full Platform tier for 500-plus people around £114.5k, each over a typical 24-month term including delivery and an ongoing monthly rhythm afterwards. As a rough comparison point, that works out to roughly £34.2k in year one against a full-time analytics hire costing £4.1k to £5.9k a month in employment cost alone, before you have covered BI, governance and architecture skills a single hire will not have. We agree the fixed price and fixed scope with you before any commitment, so there are no surprises once delivery starts.

The cost of a Power BI project in the UK mid-market depends on scope, and few firms publish prices, but as honest ranges: a focused proof-of-value (one governed dataset and a key report) is typically a few weeks and a low-five-figure budget; a departmental rollout with data engineering and training is usually a few months and mid-five figures; an organisation-wide programme runs longer and is best phased. The cost driver is data complexity, number of source systems, stakeholder alignment and governance — not the number of dashboards.

You should rerun the Power BI checklist on an existing report whenever the report changes meaningfully. New page, new measure category, new audience. Also rerun annually as a baseline check, even if nothing has changed. Standards drift and reports that were excellent two years ago may not be now. The annual review is also the right moment to ask whether the report is still being used at all.

Access to workspaces should be governed through Entra ID groups, not individual user assignments. Create groups for each role (Finance Authors, Finance Viewers, Sales Authors, etc.) and assign the groups to workspaces. New starters get added to the right groups based on their role and inherit the right access automatically. Leavers get removed from the groups and lose access automatically. Individual user assignments accumulate and are easy to forget. Group-based access is sustainable.

At scale, workspaces should be structured as Dev, Test, and Prod workspaces per domain. Finance Dev, Finance Test, Finance Prod. Sales Dev, Sales Test, Sales Prod. The pattern protects production from accidental changes and gives you a place to test changes before they affect users. The cost is some workspace overhead and the discipline of using deployment pipelines. The benefit is that change becomes routine rather than risky.

Yes — if you are on Azure or the Microsoft stack, you can pick Power BI with high confidence. The integration of Power BI with Azure, Fabric, OneLake, M365, and Dynamics is deep enough that the choice becomes obvious. Looker on Azure works but you lose most of the integration advantages and add a third-party vendor relationship. The factors that might still pull you to Looker on Azure: a heavy embedded analytics requirement for a SaaS product, an engineering culture that strongly prefers code-first BI, or a deliberate multi-cloud strategy.

On Google Cloud, Looker is a strong default, particularly if your data warehouse is BigQuery. Looker plus BigQuery is one of the cleanest BI architectures available; the integration is deep and the performance is good. The factors that might still pull you to Power BI: a Microsoft-heavy application stack (M365, Dynamics), a cost preference for Power BI's lower licence cost, a preference for self-service authoring, or significant existing Power BI investment. The Google Cloud default is strong but not absolute.

BC Native reporting is included with Business Central, which is not the same as free. The cost is in hours: maintaining RDLC layouts, fixing them when BC versions change, and finding people who can work with them. The skills are scarcer than they used to be. Total cost of ownership is real even when there is no licence line item.

Yes — Fabric is often overkill for a BC-only business. If you are BC-only, modest in volume, and not pursuing advanced analytics, Power BI direct on BC is enough. The integration tax of Fabric does not earn its keep. The threshold for Fabric being the right answer is usually one of: a second material data source, a data volume problem, or a clear analytics ambition beyond standard reporting.

Hopton's training is tailored to your specific environment, not generic. We build training sessions around your actual data models, dashboards, and business context rather than delivering a generic off-the-shelf course, because training that uses real, relevant examples transfers far better than abstract exercises.

Jet is partly a competitor to Power BI. They overlap on BC analytics, but the centre of gravity is different. Jet is finance-led, Excel-shaped, and BC-focused. Power BI is broader, supports more sources, and serves a wider audience. Many BC organisations use both. Jet for finance, Power BI for everyone else. That is a sensible split, not a contradiction.

Yes — Jet is still being invested in. Jet's owner, insightsoftware, continues to ship updates. The product is mature rather than declining. The strategic question for BC organisations is not whether Jet will keep working but whether it remains the right tool as ambitions grow. For the use cases it serves well, it remains a solid answer.

LookML is not strictly better than DAX; the comparison is unfair because they solve different problems. LookML is a modelling language for defining the semantic layer. DAX is a calculation language for defining measures within a model. Power BI uses DAX inside its semantic models; Looker uses SQL aggregations defined in LookML. Both have learning curves. DAX is famously tricky for newcomers; LookML requires SQL fluency. Neither is universally better. The right comparison is between the overall modelling experience, not the languages in isolation.

Whether Looker is worth the higher cost is sometimes yes, sometimes no. For organisations where embedded analytics is a core product capability, Looker's pricing is rational because the alternative is building an analytics layer in-house. For organisations doing internal BI on top of a Google Cloud data warehouse, Looker's cost is harder to justify against Power BI for the same outcomes. The cost-benefit calculation depends on what you actually need the platform to do. Buying Looker for use cases that Power BI handles equally well is paying a premium for capability you do not use.

No — Microsoft Fabric is not required for Business Central reporting, but it usually pays back. Power BI direct on BC works for single-source, modest-volume scenarios. Once you have multiple sources, larger data volumes, or AI ambitions, Fabric becomes the right answer. Most mid-market BC implementations we work on now use Fabric, because the integration tax of running multiple BI tools usually exceeds the cost of Fabric capacity. The decision is covered in the BC Reporting Options FAQ.

No, and the LinkedIn posts suggesting Microsoft is moving everyone off ODBC to ADBC have the scope wrong. ADBC is a genuinely faster connectivity option for the systems that support it, but ODBC is not being removed, and the great majority of Power BI connections are unaffected. It is worth understanding the difference so you can take advantage of ADBC where it helps, without acting on a claim that overstates what is actually changing.

Yes — for specific use cases, PPU is a good middle ground between Pro and Fabric. For broader use cases, often not. PPU is best when you have a small number of users who need Premium features and the rest of the organisation is fine on Pro. Once you have more than fifteen or twenty PPU licences, Fabric capacity usually becomes more economical and gives you broader capability. PPU is a tactical answer for a specific need rather than a strategic platform decision.

Power BI Report Server is not automatically the right choice just because you already have SSRS. If your current SSRS reports are working well and there is no compelling reason to move to the cloud, Report Server is a reasonable, lower-disruption upgrade path. But if nothing is forcing an on-premises requirement, the cloud service is usually the better long-term choice given its faster feature pace and lower infrastructure overhead.

Power BI Report Server and SSRS are closely related but not identical. Power BI Report Server evolved from SSRS and can host the same paginated reports SSRS ran, alongside Power BI reports, in a single on-premises platform. Organisations already running SSRS often see Power BI Report Server as a natural upgrade path that adds Power BI reporting without giving up on-premises control.

Yes — Power BI is strong enough for CRM-grade reporting. The volume challenge in CRM is rarely the size of the data; it is the data quality and the modelling. Pipeline records that have not been updated for months. Opportunities tagged with the wrong stage. Account hierarchies that have drifted. Power BI handles the volumes well; the work is in the Silver layer where the data quality issues get cleaned and the modelling decisions get made. Most CRM Power BI estates that struggle have a data quality problem (uncleaned source data, no governance) rather than a Power BI problem.

Power BI is the right tool for most mid-market UK businesses on Sage 200, yes. Power BI integrates with the Microsoft 365 stack most Sage 200 users already have, handles the cross-source reporting Sage 200 cannot, and scales economically through to multi-channel and multi-company environments. There are alternatives (Microsoft Excel with Power Query, third-party Sage-specific tools, dedicated BI platforms), and we cover the comparisons on a case-by-case basis. Power BI is the most common answer because it usually fits the requirement and the budget.

Power BI training is not a one-off event; both an initial programme and periodic refreshers work best. Power BI itself evolves with new features, and organisations bring on new staff who need the same grounding the original cohort received. We build refresher sessions into ongoing Continuity support rather than treating training as a single, one-time event.

Yes — it is possible to over-engineer Power BI security for a mid-market organisation. Highly granular, enterprise-grade security models designed for organisations with thousands of users and complex regulatory requirements can be genuinely counterproductive for a fifty-person business, adding maintenance overhead without a matching risk to justify it. We size the security model to the organisation's actual risk profile, not to a theoretical maximum.

Methodology and capability reinforce each other rather than one being more important than the other. Methodology without capability produces consistent failure. Capability without methodology produces inconsistent results. The best firms have both: a defined approach that is genuinely followed by capable consultants. The methodology should be visible in the proposal (described, not just referenced) and visible in delivery (the engagement actually follows the described approach). Methodology that exists only on the website is a red flag rather than a credential.

Self-service BI is not just about giving everyone Power BI, and that confusion is part of why so many rollouts fail. Self-service BI is about matching the right capability to the right audience and integrating it into how people actually work. Giving everyone the same authoring tool produces a small number of users who become productive and a large number who do not. The framework distinguishes between audiences and provides the right experience for each. One size fits no one.

Static RLS (a separate role manually maintained for each user or group) works for small, stable user populations where role assignment rarely changes. Dynamic RLS (where the filter expression references a table mapping users to their permitted data, so no manual per-user role maintenance is needed) scales far better and is what we recommend for any organisation beyond a handful of report consumers.

The Hopton design approach is not solely a Microsoft-led recommendation - there are genuine alternatives. Native BC reporting works for simple needs. Jet Reports (insightsoftware) is mature and Excel-based, well-suited to finance teams. Cosmos (BiE) is a newer cloud-only BC-specific option. Each has its place. We cover the comparison properly in our BC Reporting Options FAQ. Power BI is right for users who need cross-source analytics, self-service capability, or the foundation for AI and machine learning. Power BI is not always the right answer; it usually is when the requirements extend beyond BC-only finance reporting.

Roughly seventy per cent of the checklist applies to any BI tool. Layout, consistency, KPI design, accessibility, storytelling and trust are universal. The remaining thirty per cent is Power BI specific: visual headers, slicer behaviour, refresh dates, custom visuals and similar. If you are using Tableau, Looker or another tool, most of the list still helps you. We may publish tool-specific versions in time.

No — it is not only relevant to organisations on Premium or Fabric. Many of the scale problems show up before Premium or Fabric. The architecture decisions (one model per domain, star schema, deployment pipelines, model-layer security) apply equally to Pro-tier deployments. The capacity decisions matter when you are on Premium or Fabric, but the modelling and governance decisions matter regardless. Wait until you are on Premium and you have already accumulated the technical debt.

DAX training should be built around your own data wherever possible, rather than generic. Teaching DAX concepts using a generic sample dataset is faster to prepare but transfers less effectively than working through real measures against your organisation's actual sales, finance, or operational data, which is what your team will be building against once training ends.

Yes — you should probably read this even if your decision is already made. The most useful part of this FAQ is the section on when each platform is the right answer. If your decision was made on incomplete information (cost only, vendor lock-in concerns only, or a senior stakeholder's preference), the comparison may surface things worth revisiting. If the decision was made deliberately on the right factors, this FAQ confirms the reasoning. Either outcome is valuable.

You should run the Power BI design checklist on every report that goes to a real audience before sign-off. Skip it for sandbox or proof-of-concept work where the review effort would outweigh the value. The risk is in the reports that quietly become production while everyone assumed they were prototypes. The checklist is the moment the report has to declare itself.

Power BI security needs ongoing maintenance, not just a one-off design at launch. Roles change, new data sources get added, and new report consumers join the organisation. We build periodic security review into Continuity support arrangements rather than treating the initial configuration as permanent.

Yes — administrators should be trained separately from report builders, even if it is the same person, because the skill sets are genuinely different. Workspace security, capacity management, and tenant governance settings are administrative concerns distinct from data modelling and DAX, and combining them into one generic session tends to under-serve both topics.

Business users should generally not publish their own reports directly to production workspaces. We recommend separating a development or self-service workspace, where trained users can build and test their own reports, from certified production workspaces, where only reviewed and approved content is published for wider consumption. This preserves self-service flexibility without compromising the trust of governed reporting.

Almost always, yes — every KPI should show a comparison. A KPI without a comparison is a fact. A KPI with a comparison is information. Some metrics are genuinely standalone: cumulative totals for the year, count of open issues, and similar. Most are not. The discipline of asking 'compared to what' for every KPI you put on the page tightens the report considerably.

Not every employee should be able to create their own Power BI workspace by default, in most mid-market organisations. Unrestricted workspace creation tends to produce sprawl - many small, ungoverned workspaces with unclear ownership. We generally recommend restricting workspace creation to a defined group, with a clear request process for anyone else who needs one.

Every report that goes to a real audience should be developed in Dev first. Sandbox or proof-of-concept work can happen wherever. The risk is in content that drifts from sandbox to production without anyone noticing. The discipline is that Prod is for content that has been through Dev and Test, and content that has not been through that cycle does not get into Prod. Enforce this through workspace permissions, not just through process.

No — you should not always size up to F64 if you are close to the crossover. The crossover is a financial threshold, not a target. A 220-staff organisation running F8 plus 180 Pro licences (around £3,030 per month total) is doing the right thing. Moving them to F64 (around £5,400 per month with reservation) makes them spend more, not less, because the viewer count does not justify it. F64 is right when the viewers genuinely outnumber the crossover. Below that, the smaller capacity plus per-user model wins.

It is usually the wrong question, because the two are built for different jobs and most businesses that get value from one eventually want the other. Power BI answers what is happening; Power Apps answers what you do about it. Neither replaces the other, because neither is trying to do the other's job. The better question is where seeing and doing currently live in separate places in your business, because that gap is where connecting the two pays back.

You should almost never move your invoices and statements off Business Central Native reporting. Native does this well, and the alternatives (Power BI Paginated, Jet) are typically more effort for less polish on this specific use case. The exception is if you are already on Fabric and want consolidated reporting. Power BI Paginated on Fabric is a credible alternative there. For most BC organisations, Native stays.

You should usually not pick the cheapest Power BI consultancy that meets your requirements. The lowest day rate is rarely the lowest total cost when you account for engagement length, rework, and the value delivered. A more capable consultancy at a higher rate often produces a faster, cleaner outcome than a less capable one at a lower rate, and the total cost is similar or lower. The right question is not 'which firm has the lowest rate' but 'which firm produces the best total outcome for the budget available'. The two answers are often different.

Native reports for operational documents stay. Native reports that are doing analytical jobs (sales summaries, inventory analysis) often move to Power BI. The split is by use case, not by tool. The migration is the moment to ask whether a Native report is doing the right job for it, not just whether to migrate it.

You probably should not standardise on one Business Central reporting tool. Most BC organisations end up using two or three tools deliberately, each in its lane. Native for operational documents, Jet or Power BI for finance, Power BI on Fabric for cross-source analytics. That is normal, not a failure of standardisation. The discipline is being deliberate about which tool serves which use case, rather than letting tools accumulate by accident.

You probably should not wait for Business Central 2026 Wave 1 before starting. The new features are improvements, not prerequisites. Implementations using earlier BC versions still work and can be upgraded. Waiting for the next release usually means waiting forever, because the next release is always coming. Start with what is available now, design the architecture to take advantage of new features as they ship, and upgrade routinely. Most of our BC clients run on the current Wave with one Wave behind on test environments.

No — you should not wait until your central reporting is fully established before doing self-service. Self-service depends on certified semantic models, but the broader reporting estate does not have to be complete. The right approach is usually to certify the models in the priority domains first, roll out self-service in those domains, and extend domain by domain. Waiting for everything to be perfect produces nothing for years. Working domain by domain produces visible value within months.

UI/UX reviews fail to stick for two common reasons. First, the review was a one-off rather than a working discipline, so standards drifted as soon as the project ended. Second, the review surfaced too many issues at once, and the team triaged them informally without proper sign-off. Reviews work when they are routine, the issues are tracked formally, and sign-off is gated on the must-fix list being empty.

The relevant designation is Microsoft Solutions Partner for Data and AI. This is one of six Solutions Partner designations Microsoft awards (alongside Modern Work, Security, Business Applications, Infrastructure, and Digital and App Innovation). The Data and AI designation requires the partner to demonstrate technical capability, delivery success, and customer reach in the data and analytics space specifically. A firm that holds it has cleared a real bar. A firm that does not is not necessarily incapable, but the certification is one useful signal.

Hopton has delivered Sage 200 engagements for mid-market clients across distribution, manufacturing, professional services, and consumer goods. Engagements have covered finance reporting, multi-company consolidation, sales analytics, stock and inventory dashboards, and integration of Sage 200 with CRM and ecommerce sources. The Sage 200 patterns transfer well across engagements; the differences are in the secondary sources and the specific dashboard set.

Microsoft has shipped tooling to make BC-to-Fabric integration smoother, including direct connectors and analytics extensions. These reduce the build effort. They do not change the architectural decision. If you need Fabric, the connectors help. If you do not need Fabric, the connectors do not change the answer.

Copilot in BC and Copilot in Power BI are both real and both have their place. Copilot in BC is useful for the operational BC user (drafting purchase orders, summarising customer activity, asking questions about specific transactions). Copilot in Power BI is useful for the analytical user (generating visuals, drafting DAX, exploring data). The two complement each other. Both work better when the underlying data foundations are right, which is the broader theme of our AI and Copilot guidance.

Dynamics 365 Sales custom entities flow through Dataverse alongside the standard entities. The same proliferation issue exists as in Salesforce: mid-market Dynamics estates accumulate custom entities and fields over time, many of them legacy. Part of the early engagement is the same triage work: which entities are meaningful, which are unused, which are duplicates. Bringing the cleaned set into the analytical layer makes the reporting genuinely useful rather than overwhelming.

The same principles apply to NAV and earlier Dynamics products. NAV (the predecessor to BC) and earlier Dynamics products can be analysed using the same Power BI on Fabric pattern. The extraction is more involved because the systems are older and the APIs are less developed, but the architecture downstream is identical. Hopton has experience working with NAV environments through to BC migrations and has clients running on both. If you are on NAV and considering options, Power BI on Fabric is a viable route regardless of whether you are also planning a BC migration.

Power BI for sales and operations teams using Sage 200 is often higher value than the finance use cases. Sales teams want customer-level analysis (who is buying, who has stopped buying, what margin each customer generates). Operations teams want stock and supply chain visibility. Both audiences struggle to get this from Sage 200's standard reports. Power BI on top of Sage 200 typically expands BI usage well beyond finance into sales, operations, and management. The total value of the platform usually exceeds the original finance-led business case.

Pyramid Analytics and other vendor accreditations are useful where they reflect specific capabilities relevant to your situation. Pyramid Analytics certification is relevant where you are using Pyramid for governed self-service on top of Power BI. Other vendor certifications (Snowflake, Databricks, Tableau, Salesforce) are relevant where those tools are part of your stack. The general principle is that the right accreditations for your engagement match the technologies you are actually using or evaluating, not a long list of impressive-looking logos.

Some Sage 200 deployments expose ODBC drivers that Power BI can connect to directly. This works for simpler reporting needs but does not scale well: query performance depends on Sage 200, ODBC connections add load to the operational system, and the lack of a dedicated analytical layer limits what you can build. ODBC is a fine starting point for proof of concept; for production reporting, the recommended pattern is to extract data into Fabric and run analytics from there.

Your existing Jet Reports can stay or go. Some BC users keep Jet for finance-team-led Excel reporting alongside Power BI for dashboards and operational reporting. Others retire Jet entirely and consolidate on Power BI. Both paths work. The decision depends on how heavily Jet is used, how comfortable finance is with Power BI's financial reporting capabilities, and the cost of running both tools in parallel. We have helped clients on both paths and are happy to advise on the right answer for your situation.

BC ships with predefined analytics views and a Power BI app. They are a useful starting point. They are not usually the end state. Most organisations outgrow the standard app within a few months and need custom semantic models tailored to their specific KPIs and definitions. Use the standard app to start, plan to evolve from it.

Year-end is a high-stress period for finance teams using Sage 200, with the standard reports often unable to produce the consolidated, multi-period, multi-company views that statutory and management reporting need. Power BI on a properly built data layer handles year-end naturally because the data is already modelled with year-over-year comparison, multi-company consolidation, and audit trails in mind. The work shifts from a frantic month of report-building to a routine process of running existing dashboards. This is one of the most-cited benefits by finance directors after the first year-end on the new platform.

A Power BI theme is a JSON file that sets a report's colours, fonts, and visual styling in one go, rather than formatting each chart individually. Hopton publishes a library of free Power BI themes, covering styles from bold and executive to accessible and colourblind-safe, plus Microsoft-branded options for Fabric, Copilot, and Dynamics 365 Business Central reporting. They're free to download and use, no account or sign-up required; apply one via View, then Themes, then Browse for themes in Power BI Desktop. If you need more than a colour scheme, such as a governed data model behind the report, that's where our consulting work starts.

Deployment pipelines are Power BI's mechanism for moving content between Dev, Test, and Prod workspaces in a controlled way. They handle the workspace mapping, the dataset rebinding, and the deployment of related items together. Deployment pipelines are essential at scale because manual moves between environments produce mistakes and inconsistency. Without pipelines, every change is risky. With pipelines, change is routine.

Sensitivity labels, part of Microsoft Purview Information Protection, classify reports and datasets by confidentiality level (for example, Public, Internal, Confidential) and can enforce protections such as restricting export or requiring encryption based on that classification. They matter most for organisations with genuine confidentiality tiers to enforce, or regulatory requirements around data classification.

The Fabric capacity tiers start at F2, around £200 per month (entry, suitable for trials and small workloads). F4 around £400 per month (small production with light usage). F8 around £1,050 per month (most common starting point for mid-market production). F16 around £2,100 per month (multi-department, more demanding refreshes). F32 around £4,200 per month (active data engineering). F64 around £6,400 per month (free viewing kicks in here). F128 and above start around £12,800 per month and scale to enterprise volumes.

There are five essential FP&A reports every mid-market business needs. Budget versus actual P&L by entity and department, with variance analysis. Rolling forecast showing the latest expected outturn against budget. Cash flow forecast covering the next 12 to 13 weeks for working capital management. Headcount and people cost reporting for the largest cost line in most businesses. Executive KPI dashboard tying financial performance to a small number of operational drivers.

There are five Power BI and Fabric overspending patterns. First, buying capacity without realising Pro is still needed. Over-provisioning capacity at launch. Never pausing capacity outside business hours. Paying for Pro licences that nobody uses. Jumping to F64 too early. Each is recoverable. Most mid-market organisations carry several at once. Together they account for most of the savings we find in cost reviews.

Self-service BI needs five foundations to work. First, certified semantic models. Tiered audiences. Governance basics applied to self-service authors. Workflow integration rather than portal navigation. The Business Value Question for self-service authors. Each foundation addresses one of the five reasons rollouts fail. They are not optional. They are not steps to do later. The successful rollouts have all five in place before the broader user base is invited in. The failed rollouts skip foundations and try to retrofit them.

The five reasons self-service BI rollouts fail are no certified content, so users cannot tell trustworthy answers from unreliable ones. No audience tiering, so the platform serves nobody well. No workflow integration, so users have to leave their normal tools to use BI. No success measure beyond logins, so nobody can tell whether the investment is working. And no governance for self-service authors, so the estate becomes the same kind of sprawl users were trying to avoid. Each is preventable. Most rollouts fail on three or four at once.

Five things change when Power BI scales. First, numbers stop matching across reports. Performance degrades. Sprawl accumulates. Security gets messy. Change becomes risky. Each is a recognisable failure mode and each has a specific architectural response. The list is not exhaustive but it covers most of the symptoms organisations describe when they tell us their Power BI estate is not working anymore.

The four storage modes in Power BI are import, DirectQuery, Direct Lake (Fabric only), and Composite. Import loads data into the Power BI engine for fast query performance. DirectQuery passes queries through to the source system in real time. Direct Lake reads directly from the Fabric lakehouse without import or pass-through, combining performance and freshness. Composite combines Import and DirectQuery in one model for specific use cases. Each has a place. Each has costs.

There are three limits of Jet. Multi-source reporting, where Jet's BC focus becomes a constraint. Large data volumes, where Excel's shape limits performance. And dashboard-style analytics, where Power BI does the visual job better. If your reporting needs grow beyond BC alone, beyond Excel volumes, or into self-service dashboards, Jet ceiling becomes visible.

The main limit of Power BI direct on BC is API throughput: BC's API is the most common constraint. For large data volumes or complex queries, the API can become the bottleneck. Multi-source reporting also struggles with the direct approach because the joins happen in Power BI rather than in a proper data layer. When either constraint shows up, the answer is to add Fabric underneath.

There are two main BC analytics products beyond Microsoft's own. Jet Reports (now insightsoftware) is mature, Excel-based, BC-focused, with a long heritage in the BC partner channel. Cosmos (BiE) is a newer entrant, cloud-only, BC-only, with a faster install time. Both are credible products. Both have specific strengths and specific limits. Either can be the right answer depending on your situation. Neither is the right answer for multi-source analytics or AI ambitions, where Power BI on Fabric is the better fit.

There are five main gaps in BC's built-in reporting. Multi-company consolidation is awkward at best and impossible at worst depending on tenant structure. External data integration is limited (BC reporting is BC-only). Semantic modelling is absent (no certified definitions, no shared model). Performance suffers on heavy queries against the live system. Formatted financial reporting (the kind finance teams need) is constrained. None of these are fatal individually. Together they are why most BC organisations end up looking at Power BI for analytical workloads.

BC extraction has several common gotchas. Posting groups affecting how transactions roll up (often missed). Dimensions in BC (the analytical type, not data dimensions) requiring careful translation. Closing entries at year-end producing apparent duplicates if not handled. Currency revaluations affecting historical comparability. Item ledger entries that are technically reversals but appear as separate transactions. Each is recoverable. None is obvious if you have not encountered it before. The whitepaper has a section dedicated to these.

There are five most common mistakes buyers make. Buying on day rate alone rather than on total cost of the engagement. Believing the pitch team is the delivery team without verifying. Skipping the references because they feel like a formality. Choosing a generalist Microsoft partner because of an existing relationship rather than a specialist who fits the work. Picking a big-name consultancy for a small engagement, where the buyer becomes a low-priority client and the assigned team is junior. Each of these is recoverable but expensive when it happens. Avoiding them is cheaper than fixing them.

There are three most common pitfalls in BC + Power BI implementations. Underestimating multi-company complexity (consolidation logic is harder than it looks). Trying to replicate Native BC reports verbatim (better to redesign for the analytical use case). And building without a Silver layer (data lands in Gold raw and the inconsistencies surface in reports). Each pitfall is recoverable but adds time and cost when discovered late. Engaging an experienced BC analytics partner reduces the risk meaningfully because the patterns are well-known.

The three Power BI audience tiers (Consumers, Explorers, Authors) are Consumers, Explorers, and Authors. Consumers want answers presented to them: dashboards, reports, scheduled emails. Explorers want to filter and slice within an existing structure: change the time period, focus on one product line, drill through to the underlying detail. Authors want to build new content: new measures, new visualisations, new reports. Most users sit in the Consumer tier. A smaller number are Explorers. Authors are the small minority. Each tier needs different capability.

The three main licensing options are Power BI Pro at £11 per user per month (raised from £8 in April 2025). Power BI Premium Per User (PPU) at £19 per user per month, adding Premium features on a per-user basis. And Microsoft Fabric capacity, starting at F2 around £200 per month and scaling to F2048 for enterprise workloads. The three are not mutually exclusive. Most organisations use Pro for authors and either PPU or Fabric for additional capability, depending on user count and workload.

You can do quite a lot in parallel with the implementation. Existing BC operations continue unchanged. Existing Native reports continue to run. Finance can keep using Jet if they have it. The new analytics layer goes live alongside existing tools, and the existing tools get retired (or kept) deliberately rather than by accident. The implementation does not require disrupting day-to-day BC use. This is one of the practical advantages of the Power BI approach over Native rebuilds.

A structured cost review typically saves double-digit percentages in the first year, without losing capability. Most mid-market organisations carry several of the five overspending patterns at once. A structured review usually surfaces them in two to three weeks and the fixes are implementable inside a quarter. The savings come from sizing capacity correctly, removing unused Pro licences, pausing capacity outside business hours, and avoiding the jump to F64 before it is justified.

At F64 and above, viewers do not need their own Pro licence to see content. Below F64, every viewer needs a Pro licence at £11 per month. F64 is the tier where the maths changes. The decision at F64 is not whether you need the capacity (F32 or smaller is often enough technically) but whether your viewer count justifies the additional cost in exchange for free viewing across the user base.

BC users typically build five dashboards first. Sales analytics by customer, product, and channel. Financial reporting (P&L, balance sheet, working capital, multi-company consolidation if relevant). Inventory and stock position. Aged debt and collections. Profitability by line of business. Each is a recognisable need that BC's built-in reporting handles partially or awkwardly. Power BI versions land within the first eight to twelve weeks of an implementation. The remaining dashboards extend from these foundations.

Sage 200 users typically build five dashboards first. Sales analysis by customer, product, and territory. Aged debt and collections with cash position. Stock and inventory with replenishment alerts. Profitability by line of business or product group. Cashflow and treasury position. Each is a recognisable Sage 200 user need that the standard reports handle partially. Power BI versions land within the first eight to twelve weeks of an implementation. The remaining dashboards extend from these foundations.

Day rates span a wide range by firm category. Big-four and major systems integrators: £1,500 to £3,000 per day for senior consultants, with junior team members at £900 to £1,500. Mid-tier firms: £1,200 to £2,000 senior, £700 to £1,200 junior. London-based boutique specialists: £900 to £1,500 senior. Regional specialists with London presence: £700 to £1,200 senior. Freelance contractors: £500 to £900 individual. The cheapest is rarely the right answer for complex engagements, and the most expensive is rarely the right answer for mid-market work. Pay attention to the cost-per-outcome rather than just the rate.

With the issues the review finds, log them with screenshots, prioritise them, and put them on the build backlog before sign-off. We use three priority levels: must-fix before release, should-fix soon, and nice-to-have. Most reviews surface fifteen to thirty issues in the first pass. After the second iteration, that drops to a handful. The review is not done until the must-fix list is empty.

"Power BI direct on BC", as a reporting option, means treating BC's own APIs as the data source and letting Power BI handle the modelling directly, with no warehouse, lakehouse, or ETL layer sitting between BC and the report. It's one of two patterns we see regularly, the other being BC data landed in Fabric first. Direct-on-BC tends to suit smaller data volumes and single-entity setups; the Fabric route suits multi-entity, multi-source, or governance-heavy requirements. Which one is right depends on scale and reporting complexity, not preference alone.

A report has clarity and purpose when a new user can answer three questions inside ten seconds: what is this report for, who is it for, and what is the headline. If any of those takes longer, the report is failing on this category. Clarity is harder than it looks. Most reports fail not because they say too little but because they say too much, all at once, with equal emphasis.

Bronze, Silver, Gold means Bronze is the raw extract from BC, landed in a lakehouse or warehouse without transformation. The data looks like BC's internal structure. Silver is the cleaned and structured version: tables joined, codes resolved, naming standardised, history made consistent. Gold is the business-ready layer: facts and dimensions that match how the business thinks about the data, ready for Power BI semantic models. Each layer serves a purpose. Skipping Silver is the most common mistake.

Fabric capacity covers everything in Fabric: data pipelines, lakehouses, warehouses, real-time analytics, data science, and Power BI. OneLake storage is included. The capacity is shared across all workloads. This is genuinely different from buying separate licences for each component. The capacity buys you the whole platform, sized to the workload it has to support. The challenge is sizing it correctly, because the same F-SKU can comfortably handle one workload and choke on another.

Hopton's Power BI vs Looker assessment covers your data platform alignment (GCP, Azure, multi-cloud, on-premises), your audience (business users, engineers, mixed), your use case mix (internal BI, embedded, both), your engineering culture, and your cost sensitivity. The assessment maps these to the platform that fits, with reasoning. Output is a written recommendation. We do not always recommend Power BI. We recommend the platform that fits, even when the recommendation costs us the build engagement.

Power BI Premium Per User (PPU) adds Premium features on a per-user licence. Larger dataset sizes, more frequent refreshes (up to 48 per day), paginated reports, AI features in Power BI, and access to Premium-only capability without buying capacity. Useful when you need Premium capability for a small number of users but cannot justify the capacity cost. PPU at £19 per user per month is roughly twice Pro and gives you Premium features for that user. Sharing requires the recipient to also have PPU or be on Premium capacity.

Power BI adds a proper analytical layer on top of BC. Multi-company consolidation handled cleanly. Integration with non-BC sources (CRM, ecommerce, custom systems). Certified semantic models with one definition of every metric. Heavy analytical queries running outside BC, so the operational system is not affected. Formatted financial reporting that matches what finance teams need. Dashboards and self-service analytics that BC's built-in reporting does not provide. The same data, with materially better tooling around it.

Power BI at scale means more users, more reports, more authors, more domains, and more dependencies. The shift from one-person Power BI (where one BI developer can hold the whole estate in their head) to scaled Power BI (where the estate has its own architecture and governance). The transition is not gradual. There are five specific things that change, often suddenly, and organisations that do not adapt the way they work end up with a sprawl that is hard to govern and easy to mistrust.

Power BI direct on BC means connecting Power BI to BC using the standard BC connector, with no separate data warehouse or lakehouse. Power BI pulls data via BC APIs, models it semantically, and serves reports. It is the simplest path from BC data to Power BI dashboards. For straightforward use cases, it is also the right answer.

A Power BI and Fabric cost review looks at capacity tier and utilisation. Pro and PPU licence assignments and active usage. Refresh and pipeline schedules. Pause/resume automation. Reservation status. Workspace structure and capacity sharing. Usage patterns by user type. The review combines data from the Microsoft admin portal with usage reports and sometimes interviews with the data team. Two to three weeks is enough to do this properly. Less is a quick scan rather than a review.

Implementation cost varies by complexity but most mid-market engagements come in between £40,000 and £120,000 for the build phase plus the architecture work that precedes it. Ongoing licensing depends on user count and capacity sizing: typically £200 to £6,400 per month for Fabric capacity, plus Power BI Pro licences for authors. The True Cost FAQ covers licensing in detail. Total first-year cost is usually visibly less than what the BC implementation itself cost, with returns in finance team productivity and decision quality.

A Power BI on BC implementation leaves BC itself untouched - BC continues to run unchanged. Data flows from BC into Microsoft Fabric (a lakehouse architecture with Bronze, Silver, and Gold layers). Power BI semantic models sit on Gold and present certified definitions of revenue, margin, customers, and so on. Reports are built on the semantic models and delivered to users through a structured workspace. The platform supports the dashboards finance and operations need plus self-service for users who can build their own reports.

A Sage 200 Power BI engagement runs phase by phase. Most engagements start with a four-to-six week Establish phase: we audit Sage 200 and any related sources, agree the priority dashboards with finance and operations leaders, design the architecture, and produce a written engagement plan with cost and timeline. Build phase is typically eight to twelve weeks. Continuity is the optional ongoing engagement that maintains and extends the platform after launch. Most Sage 200 clients stay in Continuity because needs evolve as the business grows.

Implementation cost varies by complexity but most mid-market Sage 200 engagements come in between £40,000 and £100,000 for the build phase plus the architecture work. Ongoing licensing depends on user count and whether you need Microsoft Fabric: typically £200 to £2,100 per month for Fabric capacity at the typical mid-market scale, plus Power BI Pro licences for authors. The True Cost FAQ covers licensing economics in detail. The total first-year cost is often less than what businesses currently spend on manual finance reporting effort.

A defined methodology, in practice, is phases that follow a logical structure (discovery, design, build, test, deploy, support). A clear scope and acceptance criteria for each phase. Defined deliverables and roles. Standard architecture patterns that apply across engagements rather than being recreated each time. A defined approach to data quality, semantic modelling, and governance. The methodology should be opinionated. A methodology that says 'we adapt to whatever the client needs' is not a methodology; it is the absence of one.

A genuinely good proposal has specific scope, specific deliverables, specific team named with verifiable backgrounds, specific timeline with milestones, specific assumptions and dependencies, transparent pricing structure, honest articulation of risks and how they will be managed, defined acceptance criteria for the deliverables, and clear next steps. The good proposal reads like a working document the engagement will follow, not a marketing brochure. The volume of words matters less than the specificity of the content.

A reporting strategy engagement covers an inventory of existing reports, tools and audiences. Active versus inactive use map. Tool fit analysis per use case. Recommendations on what to keep, what to migrate, and what to retire. A target architecture and a sequencing plan. The deliverable is a written strategy you can take to anyone, including in-house. The engagement is independent of any subsequent build.

A typical Business Central on Power BI implementation runs phase by phase. Weeks 1 to 3: discovery and architecture (audit BC, agree priority reporting, design the Bronze/Silver/Gold structure). Weeks 4 to 8: build (extraction, Silver layer, Gold layer, semantic models, priority reports). Weeks 9 to 11: testing and refinement (reconciliation against BC reports, performance tuning, user acceptance). Week 12: go-live and handover. The timeline maps to a typical mid-market scope. Larger or smaller engagements adjust proportionally.

A typical CRM Power BI estate centres on a pipeline dashboard for the leadership team showing total pipeline value, weighted forecast, and movement against target. Sales rep performance dashboards with activity and outcomes. Win and loss analysis. Sales cycle analytics. Customer 360 reporting that combines CRM, ERP, and marketing data for a complete account view. A monthly board pack with the consolidated revenue forecast. The estate grows in that order in most engagements because the pipeline dashboard is the one the sales leadership team uses every Monday.

A typical CRM analytics engagement runs phase by phase. Most start with a three to four week Establish phase: discovery of the CRM data, the priority reporting needs, the architecture. The Build phase runs 6 to 12 weeks: pipeline dashboard, rep performance, win/loss, customer 360 if ERP integration is in scope. Continuity is the optional ongoing engagement after launch. The work fits alongside the existing sales operations and IT functions.

An executive FP&A dashboard is six to ten KPIs on a single page, with comparisons to budget and prior year. The KPIs are business-specific but typically include revenue, gross margin, EBITDA, cash position, working capital, and the two or three operational drivers most relevant to the business model. The dashboard is built for a five-minute scan, not for detailed analysis. Detailed analysis lives in the supporting reports. The discipline is restraint: an executive dashboard with thirty KPIs is not an executive dashboard, it is a confused report.

For years, getting a chart Power BI did not offer, or a layout the canvas would not allow, meant reaching for an SVG measure, an HTML content visual, or a stack of overlapping objects held together with hope. Those hacks work, but they take hours, break when someone resizes the page, and cannot be maintained by anyone who did not build them. Code-first reporting in Fabric makes most of them unnecessary: if you can specify a visual properly, you no longer need to smuggle it in through a workaround, which removes both the effort and the fragility.

Governance for self-service authors starts, in practice, with naming conventions for new content. Required ownership before content can be promoted. A review path before content reaches the main audience. A retirement process for content that no longer earns its place. The discipline is the same as central-team governance, applied lightly to fit how self-service authors work. The mistake is either no governance (sprawl) or heavy central-team governance (kills the self-service value). The middle path is fast review against a clear standard.

F64 includes free viewing, which sounds like a clean answer to licensing complexity. But at £6,400 per month PAYG, F64 is only economical if you have hundreds of viewers (the crossover is around 500 at list prices). Organisations sometimes jump to F64 before reaching the crossover because the licensing simplicity is appealing. The simplicity costs real money. Stay below F64 with smaller capacity plus per-user Pro until your viewer count actually justifies the move.

In evidence, sector experience looks like specific examples described credibly. The consultancy should be able to describe the data sources, the dashboard patterns, the typical KPIs, the common pitfalls, and the engagement timeline for businesses in your sector. Vague references to 'we have done lots of retail' are not evidence; specific descriptions of how retail engagements actually work are. Ask for examples and listen for specificity. A consultancy with genuine sector experience will produce specifics; one without will hedge.

Sprawl looks like twenty workspaces nobody can describe the purpose of. A hundred reports that mostly overlap. Five datasets doing roughly the same job. Authors who built something useful three years ago and have since left, with their content still running. Sprawl accumulates because adding new content is always easier than retiring old content. The annual review is the moment to push back on it deliberately.

The Business Central on Power BI implementation guide covers the technical work of building Power BI reporting on top of Business Central. The other FAQ is about tool selection: when to use Native, Jet, Power BI direct, or Power BI on Fabric. Read the tool selection FAQ first if you have not yet decided which approach is right for you. Read this one if you have decided on Power BI (with or without Fabric) and want to understand what the build actually involves.

The Power BI Consumer experience is dashboards delivered to the user, not retrieved by them. Headline numbers visible at a glance. The most common questions answered without interaction. Subscriptions delivering daily or weekly summaries via email. Mobile views for users on the move. The Consumer experience optimises for zero training and zero friction. The best Consumer experiences feel like reading a newspaper, not like operating software.

The Power BI Explorer experience is reports with rich filtering, drill-through, and bookmarks for common views. The Explorer can change the time period, switch between regions, focus on a specific product line, all without building anything new. The Explorer experience requires more report design effort up front but multiplies the reach of each report. One well-designed Explorer-tier report serves many Consumer-tier views without proliferating the underlying content.

The Power BI Health Check covers modelling patterns (star schema versus flat tables, model count, measure quality). Storage modes and refresh patterns. Workspace structure (Dev/Test/Prod or flat). Security model (RLS at model layer, group-based access, sensitivity labels). Performance (refresh times, report load times, capacity utilisation). Sprawl (overlapping content, unused workspaces). The Health Check is fast because it follows a structured methodology, not because it cuts corners.

The Self-Service Readiness Assessment covers a certified content audit (how much content has named owners, certified status, and active use). Audience analysis (who would be Consumers, Explorers, Authors). Workflow integration review (where BI currently lives versus where the audience works). Existing self-service authoring patterns (who is building what and how). Governance state for self-service authors. The assessment is fast because it follows a structured methodology and is calibrated to mid-market.

Workflow integration means the BI capability lives where users already work. Embedded in Teams. Linked from the CRM. Auto-delivered via Outlook subscriptions. Available in the meeting view of the operational tool. Self-service that requires users to navigate to a separate portal, log in, and find the right report fails because users do not have time to do that ten times a day. Integration brings the BI to where the work is, rather than asking users to come to the BI.

A Power BI domain model holds everything reports in that domain need, defined once. The metrics with their precise definitions. The dimensions used to slice them. The relationships between facts and dimensions. The measures expressed as DAX, with the business logic encoded. Reports point at the domain model and inherit the definitions. New reports do not redefine the metrics. The model is the source of truth for the domain and the reports are the views into it.

The Gold layer of a Business Central lakehouse holds business-ready facts and dimensions. A Sales Fact table with one row per transaction, with proper grain. A Customer dimension with the attributes the business cares about. A Product dimension. A Date dimension. Each fact and each dimension is the certified definition. Power BI semantic models point at Gold. Reports inherit consistency. New reports do not redefine measures because Gold is the source of truth. Gold is what makes the rest work.

The Silver layer of a Business Central lakehouse is where cleaning and structuring happen. BC tables are joined where logical (item ledger entries with their items, customer ledger entries with their customers). Codes are resolved to descriptions. Date fields are normalised. Currency conversions are applied if the business needs reporting in a single currency. History is reconciled across BC versions (because data structure can change between BC versions). Silver is the layer that turns BC's internal representation into something analytical work can build on.

When self-service authors are ungoverned, the estate becomes sprawl. Different authors build different reports answering similar questions with different definitions and different time windows. The certified semantic models get bypassed. The same problems that drove the original push for self-service reappear, but distributed across many more authors. Self-service authors need the same governance discipline as the central team, applied appropriately to their level. Without it, self-service is a sprawl factory.

After the initial implementation comes ongoing extension. The first release covers the priority domains. Subsequent releases add other domains, refine the existing ones based on user feedback, and extend into ML or AI use cases when the foundations are stable. Most clients move into the Continuity phase after launch, with regular small releases keeping the platform aligned with the business. The initial implementation is the start of the work, not the end.

If you choose Report Server now but your data residency requirement changes later, migrating to the cloud stays feasible - we design with that possibility in mind where practical, structuring semantic models and reports so they can move to the cloud service with reasonable effort if your requirements change. This is one of the reasons we discourage treating Report Server as a permanent architectural decision if the underlying driver is not itself permanent.

Nothing automatically - changes to workspace content do not appear in the published app until someone explicitly republishes it. This gives you a controlled release point, letting you finish and validate changes in the workspace before pushing them out to the wider app audience.

What happens to existing Jet reports when you move to Power BI on Fabric depends on what those reports do. Reports that are genuinely finance-team-owned, BC-only, and Excel-natural usually stay in Jet. Reports that have grown into multi-source territory or need dashboard-style presentation move to Power BI. The migration is not all-or-nothing. Audit per report and decide what stays.

Most upgrades happen without breaking analytical reporting because the architecture insulates Power BI from BC's internal changes. The Bronze and Silver layers absorb structural shifts; Gold stays stable; reports continue to work. Major BC upgrades occasionally introduce changes that need accommodation in the extraction layer, but these are usually small adjustments rather than rebuilds. We handle BC version updates as part of Continuity. Clients without Continuity sometimes see small reporting issues after BC upgrades; with Continuity, the platform stays in step.

A consultancy reluctant to provide client references is a red flag, but a soft one. Some clients genuinely do not allow public reference for confidentiality reasons (private equity, sensitive industries, competitive concerns). A reluctant consultancy might have legitimate constraints. The follow-up is to ask specifically: are there any clients we could speak to confidentially, with appropriate NDAs in place? A firm that cannot produce a single contactable reference under any conditions is signalling that the references do not exist or would not be positive.

Two patterns help when your Power BI viewer count fluctuates. First, base the decision on average rather than peak viewer count. Sporadic viewers who log in once a quarter rarely justify the licence cost. Second, F64 with reservation locks in the predictable monthly cost regardless of viewer count, which protects against growth surprises. If you are confident the user base will grow past your crossover within twelve months, the move to F64 is often worth making slightly early.

A previous Power BI self-service rollout that failed is a common situation. Most failed rollouts are recoverable with the right framework. The honest assessment usually shows that several foundations were missing and the failure was structural rather than personal. We have helped multiple clients restart self-service rollouts that had been previously declared failures, with the same audience, the same data, and the same tools, but with the foundations corrected. The relaunch is usually faster and lighter than the original.

Planning to migrate from Sage 200 to BC eventually is a common situation. The Power BI on Fabric architecture transfers cleanly. The data layer is independent of the source system, so when the migration to BC happens, the analytics layer is rebuilt to point at BC instead of Sage 200. The historical data accumulated in the analytics layer survives the migration, which preserves the years of history that BC migrations often lose. This is a strong argument for building the analytics layer before the ERP migration rather than after: the analytics platform delivers value during the migration period and protects the historical data through the change.

Not yet knowing who your internal Power BI power users will be is common, particularly for organisations new to Power BI. We help identify likely candidates during the Establish phase, usually based on who currently owns spreadsheet-based reporting or shows clear aptitude and interest, rather than assuming it should default to whoever holds a specific job title.

Running Power BI Report Server needs your own Windows Server infrastructure to host the Report Server instance, along with a SQL Server database to store report metadata and configuration. Sizing depends on your report volume, refresh frequency, and concurrent user count, and should be planned properly rather than assumed from a generic template.

ADBC stands for Arrow Database Connectivity, built on Apache Arrow, the columnar format that has become standard for moving data between analytical systems. It is faster than ODBC because data moves in columns rather than row by row, with fewer type conversions, less copying in memory, and better use of modern CPUs, and it brings security improvements like memory safety. On a big refresh of tens or hundreds of millions of rows that is a real cut in overhead, so ADBC is worth using where the source supports it and the volumes are large; for smaller or simpler connections the difference is marginal.

Cosmos has a faster install time than the alternatives because it is BC-specific and cloud-only. For organisations that want operational BC reporting quickly, with minimal setup, Cosmos is a credible answer. The trade-off is that it is BC-only and cloud-only, which means it does not extend to multi-source analytics or to on-premises BC environments. It also locks you into a specific vendor's analytical model rather than letting you build your own.

Decision Adoption Rate is the percentage of recommendations from BI outputs that result in confirmed action by the business. The metric measures whether the BI investment is changing behaviour, which is the actual point. Login counts measure activity. Decision Adoption Rate measures impact. The metric is harder to track than logins but more honest. It tells you whether the work is producing the value the business case promised.

Direct Lake is a Fabric-specific storage mode that reads directly from Delta tables in OneLake without copying data into the Power BI engine. It combines Import-like query performance with near-real-time freshness, because the lake is the storage layer rather than a separate copy. Direct Lake works only on Fabric and only against Delta tables in OneLake. For organisations on Fabric with a lakehouse architecture, it is increasingly the default choice for new models.

Jet Reports is a third-party reporting tool that lives in Excel and works directly on BC data. Finance teams have used it for years because they spend their working day in Excel anyway. Jet adds BC-aware functions and a refresh model that keeps the data current. It is sold separately from BC.

LookML is Looker's modelling language. Data engineers and analysts define the semantic model (dimensions, measures, joins, aggregations) in LookML files that live in a Git repository. The model is version-controlled, code-reviewed, and deployed like software. Reports are built on top of the LookML model and inherit its definitions. This is genuinely strong: it forces consistent definitions, prevents the drift that Power BI estates often suffer from, and supports a code-quality discipline that is rare in BI.

Power BI Report Server is an on-premises reporting platform that hosts Power BI reports, paginated (SSRS-style) reports, and Excel workbooks on servers you control, rather than in the Power BI cloud service. It is a different product to Power BI Service, licensed and deployed differently, aimed specifically at organisations that cannot or do not want their reporting data leaving their own infrastructure.

A Power BI app is a curated, packaged collection of reports and dashboards from a workspace, published as a single, polished landing experience for a defined audience. Instead of giving a business user access to the workspace itself - with all its in-progress content, development clutter, and workspace-level permissions - an app presents only the finished, approved content in a clean, navigable format.

A Translytical Task Flow lets a Power BI report write back: update, delete, or trigger actions in other systems without the user leaving the report. It reached general availability in the March 2026 Power BI update, and it changes what a report is for, because seeing the problem and doing something about it no longer live in different places. Instead of spotting an at-risk renewal or a data quality issue and then switching to an email, a ticket, or a spreadsheet, the user can act on it in place.

Certification and promotion are Power BI's way of signalling that a dataset has been reviewed and is safe to build on. Encouraging report builders across the organisation to build against certified datasets, rather than each recreating their own version of the same data, is one of the single most effective governance practices for preventing metric drift.

A good Decision Adoption Rate is above 60 per cent. 40 to 60 per cent is normal for organisations early in a self-service rollout. Below 40 per cent indicates a trust problem (the recommendations are not being trusted) or a workflow problem (the recommendations are not reaching the right people at the right moment). The rate rises as the foundations bed in. The trend matters more than the absolute number, because the baseline depends on the maturity of the existing capability.

A rolling forecast extends a fixed period forward (typically 12 or 18 months) and is updated regularly (monthly or quarterly), so the forecast horizon does not shrink as the year progresses. Power BI shows the rolling forecast against actuals and budget, with the forecast period clearly marked. The work is in maintaining the forecast inputs: the planning tool or finance team updates the forecast monthly, and Power BI presents the latest version. The discipline is more about the planning cycle than the reporting tool.

A semantic model is the governed layer that sits between your raw data and your reports. It contains the business logic, metric definitions, relationships, and security rules that all reports share. Without a well-governed semantic model, every report developer applies their own logic, which leads to inconsistency. A single, certified semantic model is the foundation of trustworthy reporting.

A semantic model is the layer where measures, relationships and row-level security are defined once and reused across every report built on top of it. In a Fabric estate a certified semantic model typically sits on top of the Gold layer, queried through Direct Lake mode, so every report and dashboard inherits the same definitions rather than each author writing their own.

A star schema is a modelling pattern with fact tables (the events: sales, transactions, page views) and dimension tables (the descriptors: customer, product, date). The star schema is the standard pattern for analytical models because it produces fast, predictable performance and intuitive measures. It is not the only pattern, but it is the one that holds up at scale. Departure from it should be deliberate, not accidental.

Governed self-service analytics is the balance between letting the business build its own reports and keeping everyone working from trusted, consistent numbers. In Power BI that means certified datasets, a semantic model that defines each measure once, clear workspace ownership, and row-level security applied consistently. Supported by training and a Centre of Excellence operating model, it lets self-service scale without descending into conflicting versions of the truth.

The main analytics-relevant features in BC 2026 Wave 1 are improvements to the Lakehouse Connector (faster initial sync, better incremental refresh handling), expanded analytics extension capabilities, deeper integration with Microsoft Fabric, and tighter Copilot integration in BC itself. The cumulative effect is that the BC-to-Fabric path is meaningfully easier in 2026 than it was even twelve months ago. The friction points that affected earlier integrations have been progressively addressed.

RLS restricts which rows of data a given user can see within a shared report, based on rules defined in the semantic model - for example, a regional sales manager seeing only their region's data while a national director sees everything, from the same underlying report rather than separate copies of it.

Self-service BI is an approach where business users can find answers in data without going through a central data team for every request. The promise is faster decisions, broader adoption, and lower demand on scarce BI resources. The reality is that most rollouts deliver none of these. Gartner data consistently shows self-service BI adoption below 20 per cent across organisations that invest in it. The gap between promise and outcome is wide enough to warrant a deliberate framework.

The Dashboard Wireframe Kit is a set of wireframe templates we share with clients for the most common dashboard shapes: executive summary, operational KPI, financial review, sales pipeline, customer health. The wireframes are the starting point for new dashboards, with the layout, the visual hierarchy, and the typical content blocks already worked out. The kit reduces design effort and produces consistent, scannable dashboards across an organisation.

The Hopton FP&A architecture pattern is Bronze, Silver, Gold in Microsoft Fabric. Bronze captures actuals from the ERP, budgets from the planning tool or Excel, headcount from the HR system, and operational data from elsewhere. Silver cleans, structures, and consolidates. Gold contains the certified semantic models for FP&A: the Group P&L model, the Cash Flow model, the Headcount model. Power BI semantic models point at Gold. Reports inherit certified definitions. The architecture is the same as for any analytical workload, applied to the FP&A use case.

The MCP server in Microsoft's Power BI Agentic tooling is a component that lets an AI agent inspect a Power BI semantic model and run DAX queries directly against it, so the agent can check its own output against the model rather than just generating a formula in isolation and hoping it's correct.

The Power BI Desktop Bridge in the new Agentic tooling is a component that lets an AI agent drive Power BI Desktop directly: reloading a semantic model and capturing a screenshot of the result so the agent can verify its own build before a human reviews it.

The Power BI UI/UX checklist is a working standard for reviewing Power BI reports before they go live. Sixteen categories cover everything from clarity and layout to accessibility, performance and storytelling. Just over one hundred individual checks. It is the same list we use internally at Hopton, written down so other teams can use it too. It is not a scoring matrix. It is not a maturity model. It is a list of questions a second pair of eyes should ask before sign-off.

The Power BI admin portal controls tenant-wide settings: export restrictions, external sharing rules, workspace creation permissions, and usage monitoring, among others. Access should be restricted to a small number of genuinely responsible administrators, since tenant-level settings affect every workspace and user across the organisation.

The biggest risk of rolling out Power BI without proper training is self-service sprawl: well-meaning business users building their own disconnected reports against ungoverned data, each with slightly different definitions of the same metrics. This recreates the exact "whose number is right" problem that migrating off spreadsheets was supposed to fix, just inside Power BI instead of Excel.

The bottleneck in CRM-ERP customer matching is account record matching. CRM accounts and ERP customers usually start as separate records and drift over time: the CRM account is the parent group, the ERP carries multiple billing entities, the names do not match exactly, and there is no shared identifier. The Silver-layer work in the lakehouse is where the matching gets done, often using a combination of name matching, address matching, and manual reconciliation for the high-value accounts. Once done, the matching becomes part of the standard data flow and stays maintained.

The cost of not adapting to scale is that numbers stop matching across reports. Performance degrades unpredictably. Security gets messy. Change becomes risky because you cannot tell what depends on what. Sprawl accumulates: many reports doing similar things slightly differently, with no clear authority for the right answer. Most organisations recognise the symptoms before they recognise the cause. The cause is usually that the architecture has not kept pace with the user base.

The difference between report consumer, report builder, and administrator training is that report consumer training covers navigating dashboards, using filters and slicers, drilling into detail, and exporting data - typically a short session for a broad audience. Report builder training covers data modelling, DAX measures, Power Query transformations, and report design - a deeper, longer programme for a smaller group of power users or analysts. Administrator training covers workspace management, security configuration, capacity management, and tenant governance - for the small number of people who will actually administer the platform.

The difference between workspace roles and RLS is that workspace roles (Admin, Member, Contributor, Viewer) control what a user can do with content - build, edit, publish, or only view - within a workspace. RLS controls what data a user can see within a report they already have access to. The two work together: workspace roles gate access to content, RLS gates access to specific rows within that content.

The headline difference between Looker and Power BI is that Looker is a code-first BI platform with a strong semantic modelling layer (LookML), tight integration with Google Cloud, and a heritage in embedded analytics. Power BI is a broader BI platform with a heritage in self-service authoring, deep integration with the Microsoft stack (M365, Dynamics, Azure, Fabric), and a much wider user base. Both are credible enterprise BI tools. The right choice depends less on tool features and more on which cloud platform your data lives on, the engineering culture of your team, and your licensing economics.

The most common Power BI security mistake you see in mid-market organisations is treating workspace access as the only security control and not implementing RLS at all, on the assumption that "everyone in the department should see everything." This usually turns out not to be true on closer inspection, and retrofitting RLS onto reports that were built without it in mind is more disruptive than building it in from the start.

The most common UI/UX mistake you see in Power BI is trying to fit too much on one page. The discipline of removing visuals is harder than the discipline of adding them. Builders feel that more visuals show more effort, and stakeholders often ask for additions but rarely for removals. The result is pages that try to answer ten questions at once and end up answering none of them clearly.

The most common mistake you see in how organisations use apps is publishing a single, flat app with every report in one undifferentiated list, rather than deliberately curating sections and audiences. This tends to happen when apps are set up quickly after reports are built, rather than planned as part of the reporting architecture from the outset.

The right amount of white space is more than feels comfortable. Power BI's default canvas tempts you to fill it. Resist. White space tells the eye where to rest and where to look next. A report that feels slightly empty when you build it usually feels right when someone else opens it. A report that feels right when you build it is often too dense for everyone else.

The right way to design a KPI card is to show the value, the unit, the comparison and the direction. Comparison means against what: previous period, target, year on year. Direction means is up good or bad. Without those four elements, a KPI card is just a number. The best test is to imagine showing the card with no other context and asking yourself: would the reader know whether to be pleased or concerned?

References from clients in your sector, with similar engagement scope, where the engagement has been live in production for at least six months. References that are too recent (less than three months post-go-live) miss the operational reality. References from very different sectors are less useful than they appear. A consultancy that cannot produce references matching your engagement profile is signalling that they have not done work like yours before, even if they say they have.

Five recognisable categories of Power BI consultancy exist in the UK. Big-four and major systems integrators (Deloitte, EY, KPMG, PwC, Accenture, Capgemini) for enterprise scale. Mid-tier consultancies (BDO, Grant Thornton, RSM, similar) for upper mid-market with broader services. Microsoft data specialists (boutique firms focused on Power BI, Fabric, and the Microsoft data stack) for mid-market focused engagements. Generalist Microsoft partners (Dynamics or M365 firms with a smaller BI practice) for clients with existing partner relationships. Freelance contractors and individual consultants for tactical work or interim capacity. Each category has a place. Knowing which one fits your engagement is the first decision.

The organisations that most commonly need Power BI Report Server are those in regulated sectors with explicit data residency requirements, businesses with specific client or contractual obligations to keep data on-premises, and organisations with security policies that restrict cloud service use for particular data categories. For most standard mid-market businesses without one of these specific drivers, we would recommend the cloud service instead.

Hopton has deep practical experience delivering Business Central analytics engagements — BC is one of the source systems we know best. Several Hopton team members come from the BC partner channel. We have completed many BC analytics engagements across mid-market clients. We have a working library of BC extraction patterns, certified semantic model templates, and dashboard reference designs. The BC Implementation FAQ covers the technical depth in detail. We are not a generalist Power BI partner with some BC experience; BC is a substantial part of what we do.

Power BI consultancies use three main pricing models. Fixed-scope, fixed-price for defined deliverables (typically used for discovery phases and well-scoped builds). Time and materials at a day rate (typically used for ongoing or open-ended work). Outcome-based or value-based pricing (less common, used where the consultancy takes some risk on the outcome in exchange for higher upside). Most engagements use a combination: fixed price for the early phases where scope is clearer, time and materials for ongoing work where the demand fluctuates.

You should ask six questions in a discovery call. What is your understanding of our situation based on what we have shared? What kind of engagement do you think this is? Who would be on the team and what is their experience? What methodology would you apply, in concrete terms? What would you expect from us during the engagement? What does the next step look like? The answers to these six questions, in a 45 to 60 minute call, give you a clear sense of whether the firm fits. If the answers are vague or generic, the firm probably is too.

You should ask references five questions. What did the consultancy actually deliver versus what they promised? What was the experience of working with the team day to day? What went wrong, and how did the consultancy handle it? Would you engage them again, and for what kind of work? What advice would you give us in setting up the engagement to succeed? The fifth question is often the most useful because it surfaces what the reference has learned that we should know.

Named Hopton clients have achieved real, published results — a few examples from case studies: Evara Developments consolidated 66 live residential developments, around 1,500 homes, from manual spreadsheet reporting into a single live Power BI view built on Business Central. Wasabi had an underperforming Microsoft estate across restaurants, central kitchens and grocery partnerships; we rebuilt it into governed reporting spanning 40-plus P and Ls in one place, and the relationship has since extended into a machine learning programme. Conspicuous Recruitment had a Power BI tool that had fallen out of use; after rebuilding the model and interface it moved to daily reliance for performance and financial reporting. Remous Print replaced manual, multi-step reporting with a live dashboard available on web, mobile, SharePoint and Teams. These sit alongside the aggregate picture across our client base: 62 organisations supported, with an average 70% reduction in reporting time and 94% data accuracy across governed reporting environments.

There are a few red flags to watch for in a pitch. Vague answers about Microsoft accreditations. Reluctance to share named team CVs or arrange conversations with the prospective delivery team. Methodology described in marketing terms rather than operational ones. References that on inspection are old, peripheral, or not actually comparable. Day rates dramatically below or above the market without clear justification. Promises that match what the buyer wants to hear too closely without surfacing genuine risks. Pitches that minimise the work the client team has to do; engagements always require client commitment, and a pitch that hides that is hiding it for a reason.

Write-back is easy to turn on and easy to regret if you skip the governance, so a few things are worth settling before the first function is written: who is allowed to trigger a write and against which records, how those actions are authenticated and logged so they can be audited afterwards, what happens if a write partially fails, and which decisions genuinely belong inside the report rather than in the system that owns the data. Getting those agreed up front is what separates a task flow that earns its place from one that quietly becomes a governance problem.

A short-form template exists for the Business Value Question for self-service authors, designed to take two minutes to fill in rather than the full BVQ. Four blocks: who is this for, what decision will it inform, what action follows, when is the deadline. Self-service authors complete the short BVQ for any content they intend to promote to a wider audience. Internal use can skip it. The discipline is light enough to actually be used. The full version of the BVQ is in the Data Governance whitepaper.

This applies to Sage 200 Standard, Sage 200 Professional, and Sage 200cloud. The technical extraction approach varies depending on which version and how it is hosted (on-premises, partner-hosted, Sage-hosted), but the architecture downstream is the same. Power BI on Fabric works for all current Sage 200 deployments. We work with clients on each variant and have established extraction patterns for each.

A good example of a well-designed Power BI theme is 149 Degrees: a warm, bold palette built around deep amber and charcoal tones, tagged Bold and Executive, designed to hold strong contrast on board-level dashboards. Other examples in Hopton's free theme library cover different needs, such as Evergreen for sustainability-themed reporting, Maple for finance teams, and Beacon and Spectrum for accessible, colourblind-safe reports. Each is a downloadable JSON file with a defined accent colour and a five-colour swatch, applied via View, then Themes, then Browse for themes in Power BI Desktop.

We recommend skipping the Power BI design checklist in a few specific cases. For genuinely throwaway prototypes where the audience is one person and the report will not survive the week, the review effort is more than the report deserves. The trap is in the reports that say they are throwaway but then do not get thrown away. If there is any chance a report will go to a real audience, run the list.

Composite mode makes sense when most of your model can sit in Import for performance but a small slice genuinely needs real-time. The classic example is fact data updating overnight (Import) combined with a small live dimension table (DirectQuery). Composite gets you the best of both. The cost is complexity. Models with two storage modes are harder to reason about, harder to optimise, and harder to maintain. Use Composite sparingly and with clear documentation of why.

Jet still makes sense in 2026 when your finance team's natural environment is Excel and your reporting is BC-centric. Jet's strength is finance-team-led reporting on BC data, with the familiarity of Excel as the canvas. The product is mature, widely supported in the BC partner channel, and well-understood by finance teams who have been using it for years. For finance reporting on BC alone, Jet remains a viable answer. The limits show up when you need multi-source, dashboard-style, or AI-augmented analytics.

Power BI Pro on its own makes sense when the workload is purely Power BI, the user count is up to a few hundred, and you do not need Premium features (large datasets, frequent refreshes, paginated reports, AI features, free viewing). Pro is the right starting point for many mid-market organisations and remains viable as the business grows. The threshold for moving beyond Pro is usually one of: a workload that needs Premium features, a viewer count that justifies F64, or a wider need for Fabric workloads beyond Power BI.

An organisation starts to need scale-aware Power BI usually around the point where there are multiple authors building reports, several business domains using Power BI, and some reports that are mission-critical to operations. The threshold is rarely about user count. It is about complexity. A 50-person organisation with three authors across finance, ops, and sales is at scale. A 500-person organisation with one BI team owning everything may not be. The shape of the team matters more than the headcount.

You should apply the Power BI design checklist three times in the build cycle. At design, before any visuals are built, to set the bar for what good looks like. Mid-build, when there is enough on the page to spot direction-of-travel issues. And before sign-off, as the last thing that happens before release. Late-stage reviews catch the most issues but the cheapest issues to fix are the early ones.

BC Native reporting is the right answer for operational documents that need pixel-perfect output: invoices, statements, packing slips, credit notes, regulatory documents. Native is built for this and nothing else does it as well within BC. It runs real-time on BC data. It handles print and PDF cleanly. It is included with BC, so there is no additional licence cost. For its narrow use case, Native is hard to beat.

Jet is the right answer when your finance team's natural environment is Excel and the reporting is BC-centric. Jet is pragmatic, fast, and finance-team-led. The fight to move finance teams off Excel is rarely worth winning, and Jet meets them where they are. For finance reporting on BC alone, Jet is often the lowest-friction answer.

Power BI direct on BC is enough when your reporting is BC-only or BC-dominant, your data volumes are modest, and your refresh frequency is reasonable. For a single-source, mid-market BC business doing typical operational analytics, this works well. The reports are fast to build, the architecture is simple, and the cost is just the Power BI licence.

Power BI on Fabric is the right answer for BC in three scenarios. Multi-source reporting, where BC is one of several systems feeding analytics. Heavy data volumes, where BC's API would struggle on direct connections. AI and forecasting ambitions, where the modern Microsoft AI stack lands first. If any of these describes you, Fabric usually pays back the additional setup cost.

A custom visual is a bad idea almost always, unless you have a specific reason the standard visuals cannot meet. Custom visuals add performance overhead, accessibility risk, and dependency on a third party who may stop publishing updates. Most reports do not need them. If you find yourself reaching for a custom visual, ask first whether a different standard visual would serve as well. The answer is usually yes.

Code-first reporting removes the technical limits that used to stop you building a bespoke visual, but removing a limit is not the same as needing to cross it. A custom visual is the wrong choice when a standard one would answer the question just as well, because every bespoke element is something your team has to understand, maintain, and carry forward when the person who built it moves on. The discipline is to reach for code when the requirement genuinely needs it, not simply because you now can.

You should not use Fabric capacity reservations when your sizing is uncertain. When you anticipate scaling up or down significantly within the reservation period. When the workload is genuinely seasonal and you would benefit from being able to pause for months at a time. PAYG is more expensive per month but more flexible. For organisations still finding their workload pattern, the flexibility is worth the premium. Reserve once the pattern is stable, not before.

You should use DirectQuery in Power BI when real-time or near-real-time data is genuinely required, such as operational dashboards monitoring live processes. DirectQuery has costs: query performance depends on the source system, many DAX patterns are limited or unavailable, and the source system bears the load of every report query. For genuine real-time needs, DirectQuery is the right answer. For 'we want fresh data' that turns out to mean 'within 24 hours', Import with frequent refresh is usually better.

Hopton's free Power BI themes page has a set of ready-made themes built for clean, modern report design: restrained colour palettes, consistent typography, and card and KPI styling that avoids the cluttered look of default Power BI reports. Each is a downloadable JSON file you apply through View, then Themes, then Browse for themes in Power BI Desktop. They're a starting point for visual consistency, not a substitute for a proper data model underneath the report.

You can find more on Hopton at hoptonanalytics.com. The website covers our team, our methodology, our published frameworks (the Hopton Insight Series), and our FAQ library across the technical and methodological topics that matter for Microsoft data and analytics work. Email hello@hoptonanalytics.com to start a specific conversation. We are happy to participate in a competitive process and equally happy to be passed over for engagements where we are not the right fit. The buyer's interests come first, even when that means we are not the answer.