IT Consulting · Capability area
Cloud & Infrastructure Consulting
The infrastructure that supports your Microsoft 365 environment. Microsoft 365 runs in the cloud, while many of the systems around it may still run elsewhere.
Active Directory, Entra ID synchronization, DNS, domain controllers, file servers, Azure workloads, legacy applications, networking, and systems inherited through earlier acquisitions can all affect a Microsoft 365 migration, consolidation, or modernization project.
Sunrise Digital Labs helps organizations understand, stabilize, migrate, and simplify this infrastructure as part of a broader Microsoft 365 strategy.
Your organization may be combining tenants after an acquisition, moving away from aging servers, or separating systems that use hybrid identity. You may also need to find out what is still running and why. We document how the current environment works, identify what depends on it, and help prepare it for change. The result is an environment that the organization can support, document, and change with a clear understanding of the systems involved.
Azure infrastructure and hybrid identity
Many Microsoft 365 environments still rely on infrastructure outside the tenant.
This may include domain controllers hosted in Azure, Entra Connect or Cloud Sync servers, virtual machines that support business applications, management systems, networking components, and services that still depend on traditional Active Directory.
We identify what is running, how the systems connect, what depends on them, and what must change before or during a Microsoft 365 migration.
Typical work includes:
- Azure virtual machines and supporting infrastructure
- Entra Connect and Cloud Sync architecture
- Hybrid Active Directory and Entra ID environments
- Domain controllers hosted in Azure
- Azure networking and connectivity
- Infrastructure dependencies that affect Microsoft 365
- Migration and consolidation planning for hybrid environments
The work keeps the infrastructure that supports Microsoft 365 available and predictable while the environment changes.
For access policies, multifactor authentication, or MFA, Conditional Access, privileged roles, and identity governance, see Identity & Access Management.
Active Directory infrastructure
Active Directory often remains a central system in a Microsoft environment after applications and collaboration services have moved to the cloud.
Before the environment changes, we document how Active Directory is structured and identify everything that still depends on it.
This includes:
- Domains and forests
- Domain controllers
- Active Directory sites and replication
- Organizational units
- Group Policy
- Service accounts
- Legacy authentication dependencies
- DNS integration
- Entra ID synchronization
- Applications that depend on Active Directory
This information is especially important during mergers, acquisitions, tenant consolidations, and divestitures.
An organization may know that it has three Microsoft 365 tenants. Those tenants may also connect to two Active Directory forests, four domain controllers, dozens of Group Policies, and applications that depend on authentication infrastructure missing from current documentation.
We identify those connections before the migration plan is set.
DNS and domain management
DNS and domain ownership affect migration timing.
Exchange Online mail flow, Teams, identity, application access, email authentication, and tenant cutovers may all depend on DNS records changing correctly at the required time.
We help organizations identify:
- Where domains are registered
- Who controls the registrar accounts
- Where DNS zones are hosted
- Which records are in use
- Which systems depend on those records
- MX, SPF, DKIM, and DMARC configuration
- Microsoft 365 verification records
- Legacy and undocumented DNS entries
- Time-to-live, or TTL, settings that can affect migration cutovers
After an acquisition, domains may be spread across registrars, hosting providers, administrators, and inherited accounts.
A scheduled DNS change requires the project team to know who controls the domain. Establishing ownership and access is therefore part of migration preparation.
For the sequence used to release and claim a domain during a tenant move, see Tenant Consolidation.
Microsoft 365 automation
Microsoft 365 administration involves the same task across hundreds of accounts or objects. Automation makes that work more consistent and creates a record that can be reviewed.
Sunrise develops automation with PowerShell, Microsoft Graph, and Microsoft 365 APIs for work such as:
- User provisioning and deprovisioning
- License assignment
- Group membership management
- Tenant inventory
- Configuration reporting
- Migration preparation
- Account validation
- Mailbox and permission reporting
- Security and configuration checks
- Post-migration validation
- Bulk administrative changes
We also use automation during discovery and migration projects. It can collect and compare information that would be impractical to gather manually across a large environment.
When useful, the automation created during an engagement can be documented and handed over to the client's internal IT team.
File servers and legacy workloads
Moving email to Microsoft 365 leaves the organization's file shares, servers, applications, and legacy systems in place until each one has a defined destination.
Before deciding what should move, we document what is present.
For file environments, this can include:
- File server inventory
- Share and folder structure
- NTFS permissions
- User and group access
- Data volume
- File age and use
- Duplicate or obsolete data
- Application dependencies
- Service accounts
- Scheduled tasks
- Backup requirements
We then classify workloads according to what should migrate, remain, be archived, or be retired.
For many organizations, this work supports a later move of suitable content into SharePoint Online, OneDrive, Teams, Azure, or another target platform.
The inventory gives the organization a basis for deciding what belongs in the future environment. It also identifies applications, permissions, accounts, and scheduled work early, so they can be addressed with the data before the file copy starts.
On-premises decommissioning
A migration can remove infrastructure after its purpose has ended. Before a system is retired, the organization asks one question:
“Can this server be turned off safely?”
We identify everything that still depends on it, including:
- Applications
- File shares
- Scheduled tasks
- Authentication services
- Certificates
- DNS services
- Print services
- Service accounts
- Backup jobs
- Scripts
- Integration processes
- Legacy systems that were never formally documented
We use those findings to build a staged decommissioning plan. Each dependency is moved, replaced, or retired before the system that supports it is shut down, so systems come out of service deliberately rather than staying online because nobody is certain what they do.
Removing unneeded infrastructure reduces technical debt, security exposure, support work, and infrastructure cost after the migration.
Cloud and licensing cost optimization
Microsoft environments accumulate costs as people, projects, and businesses change.
Licenses may remain assigned to former employees. Acquired businesses may keep separate agreements. Azure resources may continue running after their projects end. Duplicate services may remain with an undocumented purpose or set of dependencies.
We review the environment for specific opportunities to reduce unnecessary spending, including:
- Unused Microsoft 365 licenses
- Duplicate licensing
- Licensing inherited through acquisitions
- Inactive accounts that consume entitlements
- Underused Azure virtual machines
- Orphaned cloud resources
- Unnecessary storage
- Legacy infrastructure that can be retired
- Services duplicated across business units or tenants
Where the information is available, each recommendation is tied to the actual resource and its cost.
This is not a vague promise of “cloud savings.” The review identifies what can change, why the change is supported, and what the organization currently pays for the resource. It also records the dependencies that must be resolved before a license, service, or system can be removed.
Infrastructure as code
Infrastructure as code defines cloud infrastructure in files that can be reviewed, repeated, and used to rebuild an environment.
Instead of configuring resources by hand in an administrative portal, teams can define infrastructure with Terraform or native cloud deployment technologies and manage it through controlled source configuration.
We can help with:
- Terraform
- Existing infrastructure-as-code environments
- Comparing deployed infrastructure with its source configuration
- Rebuilding infrastructure consistently
- Bringing manually created resources under controlled configuration
- Supporting cloud migrations and environment consolidation
This work is especially useful during acquisitions and modernization projects, where the organization needs to know what infrastructure exists and how it can be reproduced and maintained.
DevOps and Kubernetes
Some environments include application platforms alongside Microsoft 365 and traditional IT infrastructure.
During an acquisition or consolidation, these platforms may need to be inventoried, transferred, documented, or integrated into the acquiring organization's technology environment.
Our work can include:
- Continuous integration and delivery, or CI/CD, pipelines
- Git-based deployment workflows
- Containerized applications
- Docker
- Kubernetes
- Azure Kubernetes Service
- Supporting cloud infrastructure
- Deployment automation
- Environment discovery and documentation
Sunrise works directly with these platforms as part of a broader infrastructure, migration, or integration project, to whatever depth the engagement calls for.
Monitoring and observability
Monitoring gives support teams information about system behavior before users report outages.
We design and implement monitoring for the systems that matter. This can include:
- Infrastructure monitoring
- Application monitoring
- Centralized logging
- Performance metrics
- Health dashboards
- Alerting
- Availability checks
- Log collection
- Monitoring architecture
The monitoring should answer useful operational questions and route alerts to people who can act on them. Its design should focus the team on alerts with a defined action.
Sunrise builds and documents the monitoring. The client's internal IT or operations team then runs it.
AWS and multi-cloud environments
Microsoft-focused organizations often inherit infrastructure running in other cloud environments.
An acquisition may introduce AWS workloads. A business unit may operate a standalone application in another cloud. A legacy project may still have infrastructure that nobody on the current IT team originally deployed.
When these systems affect a migration or consolidation, we determine:
- What exists
- Who owns it
- What it costs
- Which applications depend on it
- How it connects to the rest of the environment
- Whether it should remain, migrate, consolidate, or be retired
Our primary depth remains within the Microsoft ecosystem. We work across other clouds when they are part of the technology estate that must be understood or transformed.
Where this leads
You do not need to know which of these services you need before talking to us.
That is often the point.
Your organization may have completed acquisitions, accumulated several Microsoft 365 tenants, or inherited infrastructure. Its current environment may now be only partly documented.
The first step is to establish what exists, how it connects, and what depends on it. Those findings show what should migrate, stay, change, or be retired.