How to connect an on-premises ERP with a modern cloud CRM without a major overhaul or forced migration
Jacek Szafader September 10, 2026 You're reading:
- The starting point: a system that works — and a company standing still
- Three questions that decide the project
- What you're really buying: ERP–CRM integration in the language of outcomes
- The risk the board should actually be afraid of
- Security in the board's language: four questions, four answers
- Compliance that works in the process, not in a binder
- Hybrid architecture: a stage of maturity, not a half-measure
- Three scenarios from practice
- The most common concerns and straight answers
In brief, for the board. Most mid-sized European companies aren’t facing a choice between “cloud or server.” They’re facing the question of how to get sales, marketing and finance working on the same data, given that the ERP is staying exactly where it is. The answer is hybrid architecture — a model in which the finance and warehouse system stays on-premises, while the customer relationship, automation and reporting layer moves to the cloud. This isn’t a technical compromise. It’s an economic decision: you buy the business outcome without paying for the risk of a full-scale migration.
The starting point: a system that works – and a company standing still
Let’s start with a picture that repeats itself across dozens of organisations throughout Europe. A manufacturing or distribution company, a few hundred employees, two or three legal entities. At the centre of everything sits Dynamics NAV or Business Central, installed on the company’s own server. The system has been running for well over a decade, it’s wrapped in customisations, wired into the warehouse, the bank, sometimes the production floor. Nobody in their right mind wants to touch it.
The problem lies elsewhere. Sales runs its pipeline in a spreadsheet and an inbox. Marketing can’t prove who consented to being contacted. Service logs tickets in a separate file. When the board asks for a sales forecast set against stock levels, what follows is a two-day exercise in manually stitching data together — and the result is already out of date on the day it’s presented.
This isn’t a technology problem. It’s an operating cost with no owner on the P&L. A salesperson calls logistics instead of selling. A customer gets set up twice because nobody saw they already existed. The quote and the invoice carry different terms because they were created in two disconnected worlds. Each of these on its own is trivial. Together they create constant friction that scales right along with the company.
And then the idea appears: let’s add a CRM. Dynamics 365 Sales, a marketing module, process automation. All of it runs in the cloud only. That’s the moment the real conversation starts — and it isn’t about technology.
Three questions that decide the project
The business asks: what do we actually gain?
The board and legal ask: who has access to our data?
IT asks: will we have to open ourselves up to the outside world?
What you’re really buying: ERP–CRM integration in the language of outcomes
Before we get to security, it’s worth naming the benefit. Integrating an ERP with a CRM isn’t an end in itself — it’s a way to eliminate specific losses.- A shorter sales cycle.The salesperson sees availability, pricing and order history in the same window where the conversation is happening. No escalating questions to logistics and waiting until tomorrow for an answer.
- One version of the customer. A business partner is created once, in one place, with one number. No more duplicates that wreck reporting and collections.
- Quotes that match invoices. Commercial terms flow from CRM to ERP without being retyped — removing the single most common source of disputes with customers.
- A forecast based on data, not gut feel. A CRM pipeline set against ERP delivery gives the board a number it can defend.
- Marketing that survives scrutiny. Communication consents managed systemically, with a full history, instead of in a spreadsheet nobody wants to show an auditor.
- Less work that creates no value. Low-code automation takes the retyping of data between systems off people's plates.
HOW BUSINESS CENTRAL CONNECTS TO THE CRM LAYER, TECHNICALLY
- Data synchronisation — scheduled record replication, with field mapping and directional control (one-way or two-way).
- Virtual tables- live access to Business Central data via API, without copying it into the cloud. Essential for organisations that don't want to duplicate ERP data.
- Data change events (webhooks- notifying the cloud layer of ERP changes in near real time.
- Business events -triggering Power Automate processes based on events in the ERP.
The risk the board should actually be afraid of
In cloud conversations, the energy usually concentrates on the vendor: where the servers sit, who can look at the data, what the contract says. These are important questions and we’ll come back to them. But incident statistics in mid-sized companies point somewhere else entirely. Real risk rarely stems from a global infrastructure provider failing. Far more often it stems from the organisation itself losing control of identity and permissions: a former employee’s account still works, twenty people hold admin rights “just in case,” files circulate through private mailboxes, and teams — in perfectly good faith — upload company data into free AI tools that IT knows nothing about. Hence a conclusion worth stating plainly, before the first question about vendor certifications is even asked:A new system won’t fix a mess in your permissions. It will replicate it — only faster and across more data. Order in identity, access and information governance is a precondition of a CRM project, not a side effect of it.
THE IDENTITY AND ACCESS CONTROL FOUNDATION
- Microsoft Entra ID — a single identity source for the on-premises and cloud worlds. One sign-in, one point of cut-off when someone leaves.
- MFA and Conditional Access — access decisions made on the basis of sign-in risk, device, location and compliance state.
- Privileged Identity Management (PIM) — privileged roles activated for a limited time instead of permanent global administrators.
- Access Reviews — a recurring check on who still needs which permissions.
- Auditing and monitoring— a unified activity log, alerts and log retention: who, what, when and from which device.
- Data protection (DLP, classification, labels) — rules that prevent data leaving through unauthorised channels, including into external AI tools.
Security in the board’s language: four questions, four answers
1. Do we have to open our network to the internet?
No. The standard integration model relies on a component installed inside the company’s own infrastructure, which initiates the connection outbound itself and never accepts traffic from the internet. From the board’s perspective that means the company’s attack surface doesn’t grow, and deployment is measured in hours, not weeks. Only at greater scale is a dedicated circuit worth considering — and that too stays off the public network.THREE MODELS FOR CONNECTING ON-PREMISES ↔ CLOUD
Push model — on-premises data gateway. A Microsoft service installed on the customer’s server, communicating exclusively over outbound connections (TCP 443, 5671, 5672, 9350–9354). No inbound ports, no public IP address. Credentials for local data sources are encrypted asymmetrically and only decrypted on the gateway machine. The same gateway serves Power BI, Power Automate, Power Apps and Logic Apps. Deployment time: on the order of an hour.
Pull model — Azure ExpressRoute. A dedicated telecom circuit between the customer’s infrastructure and a Microsoft data centre, most often delivered at OSI layer 2 via a national internet exchange. Traffic doesn’t travel over the public internet. The public peering variant also lets you route traffic to public Microsoft 365 and Dynamics 365 endpoints over that circuit. Keep the proportions in mind: the cost is often lower than intuition suggests, but the bottleneck is time — you need to involve the carrier and plan the physical route.
Middle ground — software-defined networking (SDN). WireGuard-class solutions building peer-to-peer connections with no inbound traffic on either side.
Recommended path: start with the on-premises data gateway, move to ExpressRoute as your cloud footprint scales. Keywords: on-premises data gateway, Azure Relay, ExpressRoute private/public peering, hybrid connectivity.
2. Who holds the key to our data?
By default, data is encrypted — both in transit and at rest — with keys managed by the vendor. For organisations that need further-reaching control, there’s a customer-managed key model: the key is created and lives in a vault belonging to the company, the company rotates it, and in an extreme scenario can revoke the vendor’s access to its own data by withdrawing permissions to the key.
One caveat has to be put on the table honestly. Encryption and decryption operations happen on the cloud side, not on company premises. A model in which the vendor never sees data in plaintext is achievable for an archive or a backup — but not for an application that has to process that data. This isn’t a limitation of one particular product; it’s the definition of software as a service. So the question isn’t “do we trust,” but “whom, to what extent, and on the basis of which contractual terms.”
ENCRYPTION AND THE CUSTOMER-MANAGED KEY (CMK)
In transit: traffic protected by TLS; communication between the vendor’s own services travels over its network backbone, not the public internet.
At rest: all customer data in Power Platform and Dataverse is encrypted by default with a Microsoft-managed key; Dataverse uses database-level encryption (TDE), with data distributed across Azure SQL, Azure Blob Storage, Azure Search and Azure Data Lake, among others.
CMK (customer-managed key): an RSA key — also available as RSA-HSM and Azure Key Vault Managed HSM — created in the customer’s Azure Key Vault, linked to a Power Platform enterprise policy and assigned to a Dataverse environment. The customer rotates the key and can revoke access. Key versioning allows rotation without environment downtime.
Scope: Dataverse, Dynamics 365 Sales, Customer Service, Field Service, Customer Insights, Finance & Operations apps, Copilot Studio, Power Automate.
Limitations to verify before you start: some features — including Dataverse search, elastic tables, offline mode in the mobile apps and the activity log — have historically remained on the vendor-managed key. CMK coverage should be confirmed for your specific list of services, not assumed blind.
Where is our data stored?
This question has a far simpler answer today than it did five years ago. Microsoft runs the EU Data Boundary programme — a commitment to store and process customer data within the borders of the European Union and EFTA for Azure, Dynamics 365, Power Platform and Microsoft 365. The first phase, covering customer data, launched in January 2023; the second, covering pseudonymised personal data from system logs, in January 2024.
What the programme doesn’t settle: it doesn’t replace the controller’s own compliance programme, and it doesn’t cover every service and scenario. Typical exclusions include global technical support and threat intelligence services. This is something to verify for your specific set of services, not a general assurance to quote on a slide.
Are we compliant?
Here a distinction is needed that saves projects months. Technical compliance and contractual compliance are two separate streams of work. The first answers the question of whether the platform can meet the requirements — encryption, accountability, the right to be forgotten, consent management. The second answers whether the vendor contract’s terms match the reading of the regulations adopted by that particular company’s legal department.
Experience from projects across different EU countries is unambiguous: the platform is rarely the blocker. The blockers tend to be the vendor’s limitation of liability, the sub-processor list and the scope of audit rights. Those are topics for lawyers, not architects — and they’re best started in parallel, on day one of the project, not at the end.
It’s also worth remembering that Europe’s regulatory landscape keeps getting denser. Requirements around information governance, business continuity and vendor oversight are rising regardless of whether a company uses the cloud. In that context, a well-ordered architecture with a single identity source and full auditability is an asset, not a cost.
CHECKLIST FOR THE LEGAL DEPARTMENT
Treat the vendor’s standard DPA as a starting point, not a final document — close the gaps with your own addenda.
Verify the sub-processor list and maintain it in your record of processing activities.
Establish audit rights in writing — in practice most often satisfied through SOC 2 reports and ISO 27001 certification; document the rationale for the approach you take.
Settle the limitation of liability — the most common genuine blocker in contracts with global vendors.
Confirm tenant location and type — regional variants differ in feature availability and deployment.
Plan a review of the terms every 12–24 months; contractual terms and the scope of the EU Data Boundary change over time.
Compliance that works in the process, not in a binder
Discussions about data protection tend to stay abstract — until they come down to the level of daily operations. The best example is marketing consent management, because it’s the area where companies most often breach the rules unintentionally: someone exported a list to a spreadsheet, someone else sent a campaign, nobody checked consent status.
In an integrated environment the problem disappears structurally. The marketing module works on the same contact database as the CRM, and consent is verified automatically right before send — regardless of whether the recipient qualifies for the segment. No consent means no send. It can’t be worked around by operator error, and that’s exactly the point.
For the board this translates into three concrete things: accountability to the supervisory authority, resilience to human error, and the ability to separate consents across brands, divisions and markets without building separate databases.
THE CONSENT MODEL IN DYNAMICS 365 CUSTOMER INSIGHTS – JOURNEYS
Compliance profiles — separate consent “hubs” for brands, divisions, product lines or markets; the same person can hold a different consent status in different profiles.
Purposes — processing purposes: marketing, transactional, behavioural tracking, plus any purposes the organisation defines itself.
Consent Center — a central consent register with a full change history: what, when, by whom and from which source (form, landing page, import, manual change, one-click unsubscribe).
Enforcement at send time — the consent check happens immediately before the message goes out, at the end of the customer journey.
Double opt-in — confirmation of consent from the recipient’s own inbox; it also improves list quality.
Protected fields and anonymisation — sensitive data invisible to the marketer while remaining usable for segmentation and personalisation.
Hybrid architecture: a stage of maturity, not a half-measure
The most common mistake in cloud conversations is framing the question as binary: we migrate or we don’t. In fact, for most mid-sized companies the optimum lies in the middle — and it’s a fully deliberate choice.The ERP stays where it works.
The finance and warehouse system carries on handling accounting, inventory, purchasing and order fulfilment. There’s no reason to touch a core that’s doing its job — and there are a great many reasons not to touch it in the same year you’re rolling out a CRM.The customer layer moves to the cloud.
The CRM takes over leads, opportunities, pipeline, marketing and after-sales service. Where it needs ERP data, it reaches for it through the integration layer — copying it or reading it live, depending on the decision about whether that data should leave the server room at all.Automation closes the processes.
Low-code tools let you build approval flows, notifications and supporting apps without modifying the ERP — that is, without taking on technical debt that would complicate any future migration.Staged modernisation as a funding model.
The sequence that works in practice: first the foundation (identity, security, information governance), then hybrid integration and quick wins in sales, then extending functionality. The decision on whether to migrate the ERP comes later and — crucially — is made on the basis of data from a real, running environment rather than a vendor presentation. Each stage has its own measurable outcome, so each one can be defended to the board on its own merits.Three scenarios from practice
A manufacturer with a dispersed distribution network. Orders arrive by email and phone; the ERP knows stock levels, but field sales can’t see them. After integration, the rep checks availability and the customer’s purchase history from a phone; the service desk stops acting as a middleman for status questions. The measurable effect: faster response times to RFQs and fewer orders placed for goods that aren’t in stock.
A B2B distributor with several brands. Each brand ran its own communications and its own mailing list. After rolling out a shared database with separated consent profiles, marketing works in one system while consents stay separated as the law requires. The effect: no more parallel databases, and no more risk of a campaign going to someone who unsubscribed under another brand.
A services firm with a long sales cycle. The forecast was assembled manually, based on what salespeople declared. Once the CRM pipeline was set against ERP delivery, the board got a report refreshed daily. The least obvious effect — and the one sponsors mention most often: fewer meetings spent establishing what the current state actually is.
The most common concerns and straight answers
The concern we hear | The straight answer |
|---|---|
“The cloud is just someone else’s computer.” | In a SaaS model that shortcut is misleading and leads to bad decisions. It’s only integration with on-premises systems that introduces infrastructure components — and those are what require architectural design, not the application itself. |
“We’ll have to let internet traffic into our network.” | No. The standard model relies exclusively on outbound connections, with no inbound ports opened and no public IP address (Box 3). |
“A dedicated circuit to the cloud is only for large corporates.” | Not true. The cost is often lower than intuition suggests. The real barrier is the carrier’s delivery time, not budget. |
“The vendor can read our data.” | By default the data is encrypted with the vendor’s key. Under CMK the key sits in the customer’s own KMS, which controls rotation and can revoke access. Cryptographic operations, however, remain on the cloud side — an inherent feature of the service model (Box 4). |
“Our data will leave the European Union.” | The EU Data Boundary programme commits to storing and processing customer data and pseudonymised personal data within the EU/EFTA for the services it covers. Exclusions exist and should be analysed for your specific set of services. |
“If the service is GDPR-compliant, the topic is closed.” | No. Technical compliance is one thing, contractual compliance another. The DPA, sub-processors, audit rights and limitation of liability require separate legal analysis (Box 5). |
“We’d have to migrate the whole ERP at once.” | No. Integration through a shared data layer — with synchronisation or live access — lets you use a cloud CRM without touching the ERP (Box 1). |
“We don’t have the IT capacity for this.” | The scope of the first stage is deliberately narrow: the identity foundation and one integration. Deploying the connecting component is measured in hours. The real burden isn’t IT — it’s the business time spent putting the sales process in order. |