Topic page · Architecture · Strategy

One database for all business apps — Dataverse instead of silos.

An idea many in the IT discussion like, but few build: all business applications on a single data foundation — without interface maintenance, without duplicate data, without the "we'll figure it out somehow" Excel silos. Microsoft Dataverse now makes that viable in the mid-market. This topic page explains why — and under which conditions it works.

45-min architecture conversation Our apps on Dataverse

Microsoft Partner since 2007 (20+ years) 8 own apps on Power Platform & Dataverse devonso · tenant governance Mid-market focus · 50–800 employees

The problem

Interface hell is self-inflicted.

In every second mid-market project we take over, we find the same picture: the company has accumulated 8 to 25 business applications over the years. CRM here, ERP there, marketing tool separate, ticket system with its own database, HR on yet another platform, field-service app with its own mobile backend, a few Power Apps and Excel tools for self-service topics. Every application has its own purpose — and every application has its own database.

That works as long as the applications need to know nothing about each other. In the mid-market, that's rarely the case. As soon as a sales rep wants to see the shipping address from the ERP in the CRM, a service technician needs the device registry from the ERP in the field-service tool, or marketing automation needs to know the lead status from the CRM, the interface work begins.

Three realities of interfaces that no one admits before signing the contract:

Interfaces live longer than their original architects. When the solution architect leaves the company, typically no one remembers why a specific mapping rule exists. The interface becomes invisible debt.
Interfaces are the most common cause of production incidents. When an update lands on system A on Thursday evening and the interface to system B is broken on Friday morning, a 4-person team spends a whole shift looking for the reason.
Interfaces deepen the lock-in per system. Anyone who has built 12 interfaces to their ERP no longer switches the ERP. No matter how unhappy they are with the vendor.

The silo variant of this — "we'll just skip the interface" — isn't better. It produces manual Excel bridges, duplicate data entry, asynchronous truths, and compliance risks. A master-data record that is maintained slightly differently in three systems isn't just messy — it's GDPR-relevant and auditable.

The idea in a paragraph

If all apps read and write to the same database, there are no more interfaces.

The idea isn't new. Mainframe architects thought exactly this way in the 1970s. SAP commercially realized it as an enterprise solution in the 1990s. What is new: it now works in the mid-market too, with modern web architecture, without requiring a 12-month SAP S/4 project. The stack is called Microsoft Dataverse.

Dataverse is the business-data platform underneath Microsoft Power Platform and Microsoft Dynamics 365. It's not simply a SQL database in the cloud. It's a business-data model with built-in permissions, audit trails, validation rules, workflow triggers, multi-language metadata, and a unified REST API. Power Apps, Power Automate, Dynamics 365 Sales, Customer Service, Field Service, Project Operations, Copilot Studio, Teams integrations, and SharePoint links all work on the same semantic model.

This has a consequence many architects only really grasp after the first productive deployment: building a new business application is no longer "design a data schema, then build the frontend, then integrate with the other systems." It's "create Dataverse tables or extend existing ones, then build the frontend." The integration is already there, because all other apps already read and write to the same data foundation.

What it looks like concretely

Four patterns we see in productive mid-market implementations.

The theory sounds good — the question is what it means in practice. Four patterns from our engagements in recent years:

Pattern 1 · CRM + Service

Sales and Service on one account master

Classic use case: Dynamics 365 Sales and Dynamics 365 Customer Service work on the same account and contact master. When the sales rep creates an account, the service rep sees it immediately. When Service documents a ticket history, Sales sees on the next call where the shoe is currently pinching. No interface. Both apps read the same account.

Pattern 2 · Self-service apps

Power Apps for business topics instead of Excel silos

Instead of letting the marketing team maintain an Excel list in which campaign status and CRM lead assignment are synchronized manually, you build a Power App. It uses the CRM lead table in Dataverse directly, writes only a custom column for "campaign." One app, one data foundation, no interface effort — and the CRM sales rep sees the campaign assignment directly.

Pattern 3 · Field Service

Mobile technicians with account-master access

Dynamics 365 Field Service uses the same account and asset database as CRM and Service. The mobile technician sees the open tickets from Customer Service, the maintenance history, and the latest sales activities when driving up. One mobile app, the same data foundation — no mobile synchronization, no "last known state" problems in offline mode.

Pattern 4 · Custom software

Custom web apps on the Dataverse backbone

Even custom software (e.g. a customer portal or an industry-specific web app) can use Dataverse as a backend. Via the official Dataverse Web API or Power Pages, in-house developments get to the same data foundation. Even custom-built software lives on the same data master — without a separate backend to maintain.

Honest delineation

Three scenarios in which the idea doesn't fit.

We don't sell the single-database architecture as a cure-all. Three constellations in which we actively advise against full consolidation:

Highly specialized domain software with its own data depth. Anyone running SAP S/4HANA as a corporate ERP, MES control on the machine level, or specialized CAD-data management won't get that into Dataverse. That's not the goal either. The right answer here: clear Dataverse areas for the business-administration layer (sales, service, field operations, commercial reporting) and defined master-data interfaces to the specialist systems.
Regulatory separation. Compliance areas that must be organizationally and technically segregated — such as patient data in clinical IT or certain financial-services data — don't belong on the same data platform as marketing. Here too: Dataverse for the non-regulated part, separate stack for the regulated part, clear interface contracts.
Organizational transition phases. During an M&A integration, a business-unit spinoff, or a joint venture with its own IT, it rarely makes sense to force everything into a single Dataverse instance immediately. Architecture answer: multiple Dataverse environments with selective federation or clearly defined master-data synchronizations.

In all other cases — and that's the majority of mid-market landscapes we see — the single-database architecture wins clearly. Whoever has 80% of their business data on a shared platform has a structural maintenance advantage over the one keeping their 80% on twelve separate databases.

Our own apps · Dataverse-native

Eight arades products that follow this idea exactly.

We don't just believe in the single-database architecture — we've consistently built our own software solutions on it. Every one of the following apps runs on Power Platform and Dataverse. They can be bought and operated individually — and they all read on the same account, contact, and asset master if you combine them.

Industry app · Education

Solution for education institutions

Course management, participant tracking, certificate generation — on the same account and contact master as your other CRM applications.

Industry app · Associations

Solution for associations & chambers

Member management, dues accounting, event management — on Dataverse, integrated with Microsoft 365 Outlook and Teams.

P&SM

Project & Service Management

Project control with service-ticket integration — resource capacity, forecast, time tracking on a common data foundation with Dynamics 365 Sales and Customer Service.

Modular ERP

Modular ERP on Dataverse

Commercial functions — orders, invoices, master data — as modular Power Platform apps instead of a monolithic ERP system. For mid-sized companies for whom SAP is too big and Excel too little.

Trading companies

Inter Company Integration

Multiple business units on one tenant — documents, invoices, inventories consolidated. One database, multiple legal entities — without classic ERP multi-tenant complexity.

CRM in Teams

Teams integration for Dynamics 365

Dynamics 365 as a Teams tab — account master, ticket histories, sales opportunities right in the Microsoft Teams interface. One data foundation, two frontends.

licenses.arades.de

License Cost Calculator

License calculation for Power Platform and Dynamics 365 — per audience group, with NCE prices and ROI projection. A web app that shows us ourselves what the Dataverse architecture actually costs in licenses.

Power Platform Governance

devonso · tenant governance

Power Platform tenant audit, solution-catalog hygiene, DLP policy configuration. Indispensable as soon as self-service Power Apps are being built at scale.

Advisory

Architecture workshop

You have an existing silo landscape and want to check whether the transition to Dataverse makes sense? Fixed-price workshop in three formats — fixed price depending on depth.

How the transition runs

In waves, not a big bang.

The biggest mistake when transitioning from a silo landscape is trying to migrate everything at once. Realistic path in three waves over 12 to 36 months:

Wave 1 — migrate the core master (3 to 6 months). You choose one central business domain — typically CRM data (accounts, contacts, opportunities) or service data (tickets, asset master). You pull this domain into Dataverse, build the first productive app on top (typically Dynamics 365 Sales or Customer Service), and establish the data model as a single source of truth. Existing silo systems get read synchronizations from Dataverse.

Wave 2 — consolidate adjacent apps (6 to 12 months). Excel silo tools, simple third-system contracts, smaller specialist applications are rebuilt as Power Apps — directly on the Dataverse data foundation from Wave 1. Marketing automation now accesses the account master directly, the field-service technician sees the service history from the same Dataverse model, contract management runs on the same contact data.

Wave 3 — integrate or replace specialist systems (12 to 24 months). Existing specialist systems — ERP, MES, industry-specific third-party solutions — either remain with a clearly defined interface to the Dataverse master (via Dataverse Virtual Tables or connectors) or are replaced in the roadmap. Decisions here are typically case-specific and need management involvement.

What makes this path work: clear management commitment from Wave 1 onward. Anyone pursuing the idea only "in the IT department" gets stuck after Wave 1 — and then the new Dataverse instance is just another silo.

Frequently asked questions

What managing directors and IT leads regularly ask us.

What distinguishes Dataverse from a classic SQL database?

Dataverse is more than a table database. It is a business-data model with built-in permissions, audit trails, validation, workflow triggers, multi-language metadata, and a unified API. Power Apps, Power Automate, Dynamics 365, Copilot Studio, and Teams integration work on the same semantic model — without developers having to design a new data layer for every new app.

Is the single-database architecture vendor lock-in?

Yes — and that has to be a conscious decision. Anyone going with Dataverse binds themselves to the Microsoft ecosystem. The question is not whether the lock-in exists, but whether the strategic advantages (common data foundation, license levers, AI integration) justify the price. For mid-market companies with a Microsoft focus, typically yes. For firms with a strong open-source preference or regulatory sovereignty requirements, typically no — then more likely hybrid with clearly delineated Dataverse islands.

What does Dataverse cost per month?

Licensing runs via Power Apps user licenses (from €8.40/user/month for Premium Power Apps, higher tiers via Dynamics 365 licenses). Plus capacity licenses for database (10 GB included, extension from €36.90/GB/month). For a realistic mid-market calculation for 100 users with moderate data volume, you're at around €1,500 to €2,800/month — license audit via our License Cost Calculator shows the exact calculation per audience group.

Pricing notice: Microsoft adjusts list prices regularly (currency adjustments, NCE updates, plan restructurings). Figures here are indicative values from May 2026. For current prices including arades CSP conditions, see the License Cost Calculator (licenses.arades.de) ↗ daily.

When does a silo solution still fit better?

Three scenarios justify silos: first, highly specialized domain software (machine control, OT systems, industry-specific ERP such as SAP S/4HANA with its own data depth). Second, regulatory separation (compliance-separated areas, such as financial vs. sales data in regulated industries). Third, organizational separation (M&A transition phases, joint ventures with their own IT). In all other cases — and that's the majority in the mid-market — the single-database architecture wins.

How long does the transition from a silo landscape take?

Realistically 12 to 36 months, planned in waves. First wave: migrate one central domain to Dataverse (typically CRM data or service tickets, 3-6 months). Second wave: consolidate adjacent apps — self-service Power Apps instead of Excel silo tools (6-12 months). Third wave: either integrate existing specialist systems (Dataverse Virtual Tables, connectors) or replace them. A realistic path needs clear strategic commitment from management — otherwise it gets stuck at the first wave and the rest stays siloed.

Where you can dive deeper.

Platform overview

Would the single-database architecture simplify your system?

Bring your silo landscape into the architecture conversation. We honestly check whether the transition to Dataverse would make sense — or which silos you should keep for good reasons.

45-min architecture conversation Contact