ARCHITECTURAL CONTEXT
Microsoft Purview operates as a global tenant-level governance service with several critical architectural characteristics that fundamentally shape migration planning. The service maintains a single governance account per Azure Entra ID tenant, accessed through global endpoints at purview.azure.com.
The architecture relies heavily on Managed Identities that are tightly bound to specific subscriptions and resource groups. Network isolation is achieved through VNets, private endpoints, and DNS zones, whilst Key Vault provides secure credential storage for scanning operations.
CORE DEPENDENCIES
- Global governance endpoints
- Subscription-bound Managed Identities
- VNet and private endpoint topology
- Private DNS zone configuration
- Key Vault credential integration
- Data source connectivity patterns
CORE CONSTRAINT: TENANT-LEVEL SINGLETON
SINGLE INSTANCE LIMITATION
Microsoft Entra ID tenant allows exactly one Purview governance account. No parallel instances permitted.
This architectural constraint represents the most significant factor in migration planning. The singleton model means organisations cannot create a second Purview instance for parallel operations, testing, or gradual cutover scenarios. Resource Mover cannot relocate Purview across subscriptions, and the Purview resource ID remains static and non-portable throughout its lifecycle.
Managed Identities tied to the original subscription must be completely recreated during any migration, which cascades into numerous downstream dependencies. This constraint fundamentally eliminates traditional blue-green deployment patterns and requires careful orchestration of the migration sequence.
TECHNICAL IMPLICATIONS
- No dual-instance testing environment
- Complete MSI recreation required
- All RBAC bindings must be reestablished
- Data source re-registration mandatory
ARCHITECTURAL IMPLICATIONS
The singleton constraint creates a ripple effect across multiple architectural layers. Each component tightly coupled to the Purview instance requires careful consideration during migration planning.
| Component | Impact | Migration Requirement |
|---|---|---|
| Global URIs | Fixed to tenant | No action required |
| Atlas Metadata Backend | Instance-specific | Export and reimport via API |
| Network Endpoints | Resource ID bound | Complete recreation with new IDs |
| Managed Identities | Subscription locked | Regenerate and rebind all permissions |
| RBAC Assignments | MSI dependent | Reapply all role assignments |
| Data Source Scans | MSI authenticated | Re-register and reconfigure |
| SHIR Integration | Identity binding | Re-register with new credentials |
| Key Vault Secrets | MSI access policies | Remap to new identity |
OPTION 1: RESOURCE MOVER (INFRASTRUCTURE ONLY)
TECHNICAL SUMMARY
Azure Resource Mover supports migration of supporting infrastructure components but cannot relocate the Purview governance account itself. This approach allows preservation of network topology whilst requiring Purview reconstruction.
MOVEABLE RESOURCES
- Virtual Networks and subnets
- Private endpoints
- Key Vault instances
- Storage accounts (scan logs, classification rules)
- Log Analytics and Application Insights
- Private DNS zones
TECHNICAL ADVANTAGES
- Preserves existing IP address ranges
- Reduces DNS and private endpoint rebuild complexity
- Minimal impact to SHIR networking topology
- Maintains storage account continuity
TECHNICAL DISADVANTAGES
- Purview instance rebuild still mandatory
- Complete MSI recreation required
- Key Vault secrets must be remapped
- Risk of broken data lineage continuity
- No reduction in cutover complexity
OPTION 2: FULL REBUILD IN PRODUCTION
DEPLOY NEW PURVIEW INSTANCE
Create fresh governance account in Production subscription with clean resource ID
RECREATE NETWORKING
Build VNets, private endpoints, and DNS private zones aligned to Production topology
ESTABLISH MANAGED IDENTITIES
Generate new MSI and configure RBAC assignments across all dependent resources
CONFIGURE KEY VAULT
Re-link scanning credentials and establish access policies for new identity
REGISTER DATA SOURCES
Reconnect all data assets with appropriate authentication configurations
REBUILD SCANNING CONFIGURATION
Recreate scan rules, schedules, and classification rulesets
RECONSTRUCT COLLECTIONS
Rebuild collection hierarchy and domain structures according to governance model
IMPORT METADATA
Utilise Atlas API to reimport glossary terms, classifications, and custom attributes
OPTION 2: TECHNICAL TRADE-OFFS
TECHNICAL ADVANTAGES
This approach delivers the cleanest architectural outcome, establishing Production governance with proper separation from Sandbox environments.
- Clean RBAC model aligned with Production IAM policies
- VNet addressing and private endpoint layout designed for long-term governance scalability
- Enables enforcement of Zero Trust network policies from inception
- Full auditability with clean lineage tracking from Day 1
- No legacy configuration baggage
- Optimal for greenfield Production standards
TECHNICAL DISADVANTAGES
The comprehensive rebuild introduces significant implementation overhead and coordination requirements.
- Complete reconstruction of scanning and classification rules
- SHIR must be re-registered with new credential set
- Custom migration scripts required for glossary and metadata
- High dependency on client networking and IAM approval cycles
- Extended timeline for data source re-registration
- Potential metadata loss for non-exportable elements
OPTION 3: LEAVE PURVIEW IN SANDBOX
ARCHITECTURAL WEAKNESS
Maintaining Purview in Sandbox fundamentally contradicts enterprise governance principles and introduces significant technical debt.
TECHNICAL CONSTRAINTS
- Sandbox VNets lack production-grade hardening
- IAM roles not aligned to Production PIM policies
- Insufficient private link configuration for enterprise requirements
- Limited cross-subscription governance scalability
- Non-compliant with separation of concerns principles
TECHNICAL RISKS
- Misaligned DNS zones causing resolution failures
- Legacy firewall rules introducing security gaps
- No separation between test and production data lineage
- Future architectural changes blocked by single-instance constraint
- Audit trail confusion across environments
Architectural Recommendation: This option fails to meet enterprise governance standards and should be excluded from serious consideration. The technical debt accumulated will compound over time, creating increasingly severe operational constraints.
OPTION 4: STAGED CUTOVER (RECOMMENDED)
SANDBOX REMAINS ACTIVE
Existing Purview instance continues operations during preparation phase
BUILD PRODUCTION INFRASTRUCTURE
Deploy VNet, DNS zones, private endpoints, Key Vault, Log Analytics, and storage accounts
EXPORT ATLAS METADATA
Extract glossary, domains, custom attributes, and classifications via API
DELETE SANDBOX PURVIEW
Remove existing instance to satisfy tenant singleton constraint
DEPLOY PRODUCTION PURVIEW
Create new governance account in Production within minutes of deletion
APPLY RBAC CONFIGURATION
Establish role assignments for new Managed Identity
IMPORT METADATA
Rehydrate Atlas backend with exported governance content
REGISTER DATA SOURCES
Reconnect all data assets with Production authentication
VALIDATE FUNCTIONALITY
Test scans, lineage tracking, and governance workflows
Critical Note: Only one Purview instance exists at any point. "Hybrid" refers exclusively to preparation activities, not dual operation.
RECOMMENDATION AND EXECUTION PATH
RECOMMENDED APPROACH
Option 4: Staged Cutover — Balances risk mitigation with architectural quality whilst respecting tenant constraints
KEY ADVANTAGES
- Respects singleton tenant constraint
- Minimises production downtime
- Enables Infrastructure-as-Code approach
- Provides structured metadata migration
- Low-risk networking and IAM implementation
- Allows thorough testing of export scripts
EXECUTION PREREQUISITES
- Production Landing Zone readiness confirmed
- Network and DNS architecture approved
- IAM and RBAC policies documented
- Atlas export/import scripts tested
- SHIR host infrastructure prepared
- Cutover window scheduled (2–3 hours)
DISCOVERY
1–2 weeks
INFRASTRUCTURE BUILD
2–3 weeks
NETWORK CONFIG
1 week
IAM APPROVALS
1–2 weeks
CUTOVER WINDOW
2–3 hours
DATA SOURCE REGISTRATION
3–6 weeks
VALIDATION
1–2 weeks