Technology Decision Frameworks

The decisions your migration partner won’t help you make

Large consultancies sell platforms. We help you choose the right architecture for your operation — even when the right answer isn’t the most expensive one.

Every pharmaceutical wholesale migration involves a series of technology decisions that will shape your operation for the next decade. Most consultancies have a preferred stack and will steer you towards it because that’s what their team knows, what their partnership incentives reward, and what’s easiest for them to deliver.

We take a different approach. We evaluate each decision on its merits for your specific operation, your regulatory obligations, and your team’s ability to maintain what gets built. Below are the key decisions you’ll face, with honest guidance on each.

Interactive tool

Build your technology profile

Step through the key decisions and we’ll prepare a tailored assessment of your migration requirements.

Step 1 of 6

Detailed reference

Comprehensive decision frameworks

Want the full detail? Read our in-depth comparison tables and independent guidance for each technology decision below.

1

Where Does Your ERP Live?

BC SaaS vs On-Premises vs Hybrid — the deployment decision that affects everything else.

BC SaaS (Cloud) BC On-Premises Hybrid
What it is Microsoft-hosted, always current, subscription-based Self-hosted on your infrastructure or Azure VMs BC SaaS for core ERP, custom components on your own Azure infrastructure
Update cycle Two mandatory major updates per year, monthly minor updates — you cannot opt out You control when to update Core ERP updates are mandatory; your custom layer updates on your schedule
AppSource access Full access to 6,000+ marketplace extensions No AppSource access — extensions must be sideloaded manually Full AppSource for BC; your custom layer is independent
Copilot & AI Full access — included in licence at no extra cost Not available Available within BC; your custom AI runs independently on Azure
Fabric & analytics Native integration via BC2Fab / Open Mirroring Requires custom data pipeline to extract and load data Best of both — BC data flows to Fabric natively, custom data joins it in OneLake
Infrastructure cost Subscription only — no servers to manage Servers, patching, backups, disaster recovery all on you Mixed — lower than full on-prem, higher than pure SaaS
GDP validation risk Every Microsoft update is a potential revalidation event for your RP You control the update window — validate on your schedule Core ERP updates need validation; custom layer is isolated
Vendor lock-in High — deeply embedded in Microsoft cloud Lower — you own the infrastructure Medium — BC is locked in, but custom layer is portable
Best for pharma wholesale when… You want full platform capabilities and can manage the validation overhead of regular updates You need absolute control over your update cycle and have the IT team to support it You want platform capabilities but need to isolate pharma-specific workflows from Microsoft’s update cycle

Our take

For most pharmaceutical wholesalers, hybrid is the right answer — even though it’s rarely what a large consultancy will recommend because it’s harder to deliver. BC SaaS gives you AppSource, Copilot, Fabric, and Microsoft’s infrastructure. But your pharma-specific workflows — controlled drug handling, GDP compliance processes, custom warehouse interfaces — should sit in an independent layer that you control.

This means a Microsoft update never breaks your regulatory compliance, and your custom components can evolve at the pace your operation demands rather than Microsoft’s release cadence.

Pure cloud is right if your pharma-specific customisation is minimal. Pure on-prem is right only if you have a strong IT team and are willing to sacrifice the entire AI and marketplace ecosystem.

2

How Should Your Warehouse Team Interact with the System?

Power Apps vs AppSource WMS vs Custom — choosing the right interface for each workflow.

Power Apps AppSource WMS Extension Custom Web/Mobile App
What it is Microsoft’s low-code platform for building mobile and web apps on Dataverse Pre-built warehouse management apps from ISVs (Warehouse Insight, Tasklet Mobile WMS, WMS Express, etc.) Purpose-built interfaces developed specifically for your operation
Build time Fast for simple workflows (days/weeks) Install and configure (days to weeks) Longer (weeks to months) — but exactly right for your needs
Customisation depth Medium — good for forms, approvals, simple data capture. Limited for high-speed scanning Medium — configurable within the vendor’s framework Unlimited — built for your exact workflow, your devices, your speed requirements
Speed & performance Adequate for back-office tasks. Can lag under high-volume scanning Generally good — purpose-built for warehouse speed Optimised for your specific throughput — millisecond response times for speed-critical picking
Offline capability Limited — improving but still inconsistent Varies by vendor — some handle offline well Full control — build offline-first if needed
Pharma-specific workflows You build them yourself — no pharma templates General warehouse only — no GDP, controlled drug, or batch verification logic Built specifically for pharma — controlled drug scanning, batch/expiry validation, GDP-compliant pick confirmation
Maintenance Microsoft maintains the platform; you maintain your apps Vendor maintains the extension; you pay subscription You (or your partner) maintain the application
Cost model Included in Power Platform licensing + development time Subscription per user/device (typically £30–£80/device/month) Development cost upfront + ongoing maintenance
Best for… Internal approval workflows, simple data capture, dashboards, non-speed-critical mobile tasks Standard warehouse operations where your workflows fit the vendor’s model High-volume pharma-specific operations — controlled drug picks, GDP batch verification, licence-validated dispatch

Our take

The right answer is usually all three, in different places. Power Apps for internal workflows that don’t justify custom development — purchase approvals, exception handling, simple reporting. An AppSource WMS extension for standard warehouse operations where the vendor has already solved the problem well. Custom development only where the pharma-specific regulatory or operational requirements genuinely demand it.

What you should not do is rebuild everything as Power Apps (what a low-code-focused consultancy will recommend) or custom-build everything (what a development shop will recommend). Both are expensive mistakes — one gives you a system that’s too generic for pharma, the other gives you a maintenance burden you don’t need.

3

Where Should Your Data Live and How Should You Analyse It?

Power BI on BC Direct vs Microsoft Fabric vs Custom Analytics — choosing your analytics layer.

Power BI on BC Direct Microsoft Fabric + Power BI Custom Analytics (Azure)
What it is Power BI reports connected directly to BC’s OData/API endpoints BC data mirrored into Fabric’s OneLake, with Power BI, notebooks, and AI models on top Custom data pipelines and analytics models running on Azure
Data freshness Near real-time — but every report query hits your ERP Near real-time via Fast Fabric sync (<15 min). Reports don’t touch BC. You control the refresh cycle
Impact on ERP Heavy reporting can slow BC for operational users Zero impact — analytics run on a separate layer Zero impact — completely decoupled
Cross-system analytics BC data only — hard to combine with other sources Combines BC data with any other source in OneLake — logistics, temperature monitoring, external market data Full flexibility — any data source, any model
AI & machine learning Limited — Power BI’s built-in AI features only Full — Fabric notebooks, Azure ML integration, data agents Full — any framework, any model, any scale
Complexity Low — familiar Power BI interface Medium — requires Fabric setup and data pipeline configuration High — requires data engineering and ML expertise
Cost Power BI licence only Fabric capacity licence (pay-as-you-go or reserved) + Power BI Azure compute + storage + development
Best for pharma wholesale when… You need standard operational dashboards and your report load is light You want serious analytics — demand forecasting, anomaly detection, cross-system compliance reporting — without degrading ERP performance You need highly custom AI models or have data science capability in-house

Our take

If you’re moving to BC SaaS, Fabric is the natural analytics layer and you should plan for it from day one — even if you start simple. The ability to combine your BC transactional data with temperature monitoring logs, logistics provider data, and market intelligence in one place is transformative for a pharmaceutical wholesaler.

Direct Power BI on BC is fine for getting started but will hit limitations quickly as your reporting needs grow and your ERP slows under the load. Custom analytics is for specific, high-value use cases where Fabric’s built-in capabilities aren’t enough.

4

Where Does AI Actually Add Value in Your Operation?

BC Copilot vs Custom AI Agents vs External AI vs Manual — deploying AI with care in a regulated environment.

BC Copilot (Built-in) Custom AI Agents (BC Toolkit) External AI (Azure) Manual Process
What it is Microsoft’s built-in AI — chat, bank reconciliation, sales suggestions, payables agent Custom agents defined in natural language within BC’s AI Development Toolkit AI models running outside BC on Azure, called via API Your team does it the way they always have
Setup effort Zero — included and enabled by default Medium — define goals, test in sandbox, refine High — data pipeline, model training, integration Zero
Pharma domain awareness None — generic business logic You teach it your domain through natural language instructions Full control — train on your specific pharma wholesale data Your team IS the domain awareness
Regulatory risk Low — Microsoft manages the AI Medium — you’re responsible for validating agent behaviour against GDP Medium-High — you own the model, the data, and the compliance implications Low — humans make auditable decisions
Examples in pharma Chat with your data, auto-suggest payment matching, draft purchase orders Review invoices, match to POs, flag controlled drug items for RP approval, route standard items to auto-posting Demand forecasting on 10 years of purchasing data, anomaly detection, intelligent warehouse allocation Experienced buyer reviews stock, checks supplier availability, places orders on judgement
Best for… General productivity — let everyone interact with data faster Automating multi-step pharma workflows where rules can be expressed in natural language High-value analytical problems where historical data drives better decisions Processes where human judgement is critical or regulatory accountability requires human sign-off

Our take

AI in pharmaceutical wholesale needs to be deployed with more care than most consultancies will acknowledge. A generic “we’ll add Copilot” pitch ignores the reality that an AI agent auto-posting invoices in a controlled drug supply chain carries regulatory implications that don’t exist in a standard wholesale business.

Our approach: start with BC Copilot for general productivity (it’s free and low-risk). Identify 2–3 specific operational problems where AI could genuinely improve outcomes. Build a proof of concept on real data. Validate the impact. Only then embed it into production, with appropriate human oversight for GDP-sensitive processes.

The worst outcome is an AI strategy that sounds impressive in a boardroom but creates compliance exposure on the warehouse floor.

5

For Each Requirement — Build, Buy, or Configure?

A requirement-by-requirement guide to the most expensive decision in your migration.

Requirement Configure BC Buy (AppSource) Build Custom Why
General ledger, AP/AR BC’s financial core is strong — don’t fight it
Standard warehouse operations Buy if you need mobile scanning BC + an AppSource WMS handles this well
Complex wholesale pricing Partially Evaluate pricing extensions Build the gaps BC’s pricing is improving but pharma wholesale structures often exceed it
Batch & lot tracking BC’s item tracking handles this natively when properly configured
Controlled drug workflows Partially No off-the-shelf solution handles UK controlled drug compliance for wholesale
GDP audit trail & compliance Partially Build reporting layer BC provides change logs but pharma-specific compliance reporting needs custom work
B2B ordering portal Evaluate e-commerce extensions Build if pharma-specific Generic B2B portals may not handle pharma pricing, licence validation, or controlled drug restrictions
Temperature monitoring Integration to your specific monitoring hardware and GDP-compliant logging
WDA licence validation No standard BC feature validates UK pharmaceutical trading licences
Demand forecasting Evaluate Build if pharma-specific Generic forecasting won’t account for pharma-specific demand drivers
EDI / supplier integration Mature AppSource EDI connectors exist — don’t rebuild this
Financial reporting & BI Buy templates Standard reporting with BC + Power BI, possibly Fabric for advanced
Payroll & HR Buy or use separate system Not BC’s strength — use a specialist tool

Our take

The most expensive migrations are the ones that custom-build what should be configured, buy extensions for things that should be built bespoke, or configure workarounds for requirements that need proper development. Getting this classification right at the design stage saves tens of thousands of pounds and months of time.

A generalist BC consultant will default to “configure or buy” for everything because that’s faster to deliver. A development shop will default to “build” because that’s what they sell. We recommend the right approach for each requirement based on what pharmaceutical wholesale actually demands.

Ready to decide

These frameworks are a starting point.
Your operation needs specific answers.

Every pharmaceutical wholesaler’s situation is different. We work through these decisions with you, factoring in your regulatory obligations, your team’s capabilities, and your commercial constraints.