Yes. When old and new services share one database, any compromised service may read or change data it should not own, and permissions tend to stay broad because the legacy app needs them. Limit it with per service accounts, views and a plan to split the data.
Why teams share the database
Splitting code is easier than splitting data. Legacy systems often depend on a centralized database that serves many domains, with logic in stored procedures. Azure's strangler guidance acknowledges this and says services and data stores used by both old and new systems need to be handled so both can reach them at the same time.
So sharing is a reasonable temporary step. The security risk comes when it becomes permanent.
What goes wrong
- One credential for everything. The legacy app's database account often has full rights. If a new service reuses it, one flaw in that service exposes every table.
- Hidden coupling. A new service reads a table directly. Later someone changes the schema and breaks it, or worse, bypasses the validation the owning service performs.
- No audit trail by service. Queries look identical in logs, so incident response cannot tell which component touched the data.
Controls while the database is shared
- Create one database account per service. Never reuse the legacy account.
- Grant the minimum. Give each account only the tables it needs, and prefer read only where possible.
- Expose views or procedures instead of raw tables for new services, so the schema can change underneath.
- Log by account. Ensure auditing shows which account ran each statement.
- Keep connection strings out of source. Store them in your secrets manager and rotate them.
- Track every cross service table access in a simple register, with an owner and a target date for removal.
| Stage | Data approach |
|---|---|
| Start | Shared database, per service accounts |
| Middle | Views and read replicas for cross domain reads |
| Later | Domain tables moved into separate databases |
| End | Each database holds one domain |
Azure's guidance describes this last step, incrementally extracting domain specific tables and procedures into isolated domain databases until the monolithic one is fully decomposed.
Changing data across the seam
When data moves, the old and new copies can disagree. Decide which copy is the source of truth for each table during the transition, and write that down. Mistakes here become integrity incidents, not just security ones.
Pair this with a review of what the monolith's dependencies do with the database. Old data access libraries, drivers and connection pool packages carry vulnerabilities too, and they sit right in front of your most sensitive data.
Safeguard's dependency scanning covers those libraries in both the legacy and new repositories, and its compliance and evidence automation can help you keep a record of the access controls you apply. See monolith to microservices security migration for related steps.
Quick check
Is a shared database ever acceptable?
As a temporary stage with per service accounts and a removal plan, yes.
Should new services read legacy tables directly?
Prefer views or an adapter so the schema can change without breaking or bypassing checks.
Sources
Last reviewed: 19 October 2026.
