DEV Community: Apps4.Pro Migration Manager

Microsoft Purview Information Protection and Classification: A Practical Guide

Apps4.Pro Migration Manager — Mon, 22 Jun 2026 09:24:54 +0000

Every Microsoft 365 tenant has a hidden data problem.

Over time, SharePoint sites, OneDrive folders, Teams channels, Exchange mailboxes, and shared workspaces collect contracts, customer records, HR files, financial reports, intellectual property, and old spreadsheets that should probably not be sitting where they are.

Most of that content is not labeled.

A lot of it is not reviewed.

And when a tenant-to-tenant migration, compliance audit, merger, divestiture, or AI readiness project begins, the problem becomes very visible.

You cannot protect data you cannot see.

You also cannot migrate sensitive data safely if you do not know what it is, where it lives, who owns it, and how it should be handled.

That is where Microsoft Purview Information Protection becomes important.

This article explains how Microsoft Purview helps with data discovery, classification, sensitivity labels, Content Explorer, Activity Explorer, and migration readiness in Microsoft 365.

What is Microsoft Purview Information Protection?

Microsoft Purview Information Protection helps organizations discover, classify, label, and protect sensitive data across Microsoft 365.

It is the modern direction for information protection in Microsoft 365 and brings together capabilities such as:

Sensitivity labels
Data classification
Data loss prevention
Content visibility
Activity visibility
Policy-based protection

For Microsoft 365 admins, the value is simple: Purview helps answer questions like:

Where is our sensitive data?

Who is accessing it?

Is it labeled?

Is it protected?

Will it remain protected after migration?

Purview works across key Microsoft 365 workloads such as SharePoint, OneDrive, Exchange, Teams, and endpoints.

It is especially useful because protection can travel with the file. A sensitivity label can apply encryption, watermarks, access restrictions, and other controls even after the document moves outside its original location.

Data discovery vs data classification

Data discovery and data classification are related, but they are not the same thing.

Data discovery is the process of finding content across your Microsoft 365 environment.

It helps identify what exists across:

SharePoint sites
OneDrive accounts
Exchange mailboxes
Teams content
Endpoints
Other connected locations

Data classification is the process of categorizing that content based on sensitivity, business value, or compliance requirements.

For example, content may be classified as:

Public
Internal
Confidential
Highly Confidential
Restricted

Together, discovery and classification answer two important questions:

What sensitive information do we have?
How should that information be handled?

Microsoft Purview helps with both.

It can start surfacing sensitive and labeled content before every policy is fully built. This gives admins an early view of risk across Microsoft 365 and helps them make decisions based on real data instead of assumptions.

The core building blocks of Microsoft Purview classification

Purview classification is not one single feature.

It is a set of connected capabilities that work together.

The most important building blocks are:

Sensitive Information Types
Trainable Classifiers
Exact Data Match
Sensitivity Labels

Let us look at each one.

1. Sensitive Information Types

Sensitive Information Types, often called SITs, are pattern-based classifiers.

They detect data using things like:

Regular expressions
Keyword lists
Checksums
Proximity rules

Microsoft provides many built-in SITs for common sensitive data patterns such as government IDs, financial data, health-related identifiers, and other regulated information.

SITs are useful when the data has a recognizable format.

For example:

Credit card numbers
Passport numbers
Tax IDs
Bank account numbers
National identification numbers
Employee IDs
Customer reference numbers

You can also create custom SITs for your organization-specific identifiers, such as internal project codes, customer numbers, or employee numbers.

Use SITs when the question is:

Does this content contain a specific pattern of sensitive data?

2. Trainable Classifiers

Not all sensitive data follows a simple pattern.

Some documents are sensitive because of what they are about, not because they contain a predictable number or format.

Examples include:

Legal contracts
Source code
Resumes
HR documents
Financial planning documents
Customer complaint records
Policy documents

This is where Trainable Classifiers help.

Trainable Classifiers use machine learning to identify content based on examples. Instead of looking only for a pattern, they learn from sample documents and classify similar content.

Microsoft provides several pre-trained classifiers, and organizations can also build custom classifiers.

Use Trainable Classifiers when the question is:

Is this document about a specific topic or business process?

3. Exact Data Match

Sensitive Information Types can detect data that looks like a pattern.

Exact Data Match, or EDM, goes further.

EDM helps detect whether content contains values from a known source of truth, such as a customer database, employee list, patient record system, or CRM export.

For example, a number may look like a customer ID, but EDM can confirm whether that number is actually one of your real customer IDs.

This is useful for high-precision detection where false positives are costly.

Typical EDM use cases include:

Customer records
Patient IDs
Employee identifiers
Account numbers
Membership numbers
Regulated business data

Use EDM when the question is:

Does this content contain one of our actual sensitive records?

4. Sensitivity Labels

Sensitivity Labels are the protection layer.

Classifiers identify sensitive data.

Labels help protect it.

A sensitivity label can apply controls such as:

Encryption
Headers
Footers
Watermarks
Access restrictions
External sharing restrictions
Privacy settings for Teams, Groups, and SharePoint sites

Labels can be applied manually by users, recommended by Office apps, or applied automatically when Purview detects sensitive content.

A simple way to remember the relationship is this:

Classifiers find the data. Labels protect the data.

For many organizations, a simple label taxonomy works best at the start.

For example:

Public
Internal
Confidential
Restricted

A smaller label set is easier to explain, easier to apply, and easier to govern.

Check licensing before planning

Before building a Purview classification plan, check your licensing.

Some basic classification and manual labeling capabilities are broadly available, but advanced features usually require higher-level licensing.

Capabilities such as automatic labeling, Trainable Classifiers, Exact Data Match, Content Explorer, and Activity Explorer may require Microsoft 365 E5, the E5 Compliance add-on, or equivalent licensing.

This matters during planning.

A migration playbook that assumes auto-labeling and EDM are available will fail if the tenant is only licensed for basic capabilities.

Before committing to a rollout plan, confirm what the tenant can actually use.

Content Explorer: seeing what Purview found

Once classification is active, admins need a way to inspect the results.

That is where Content Explorer helps.

Content Explorer gives visibility into classified content across the tenant.

It can show items that have:

Sensitivity labels
Retention labels
Sensitive Information Type matches

Admins can use it to understand where sensitive data lives, which workloads contain the most risk, and whether classification is working as expected.

In practical terms, Content Explorer can help with:

Finding sensitive files across SharePoint and OneDrive
Reviewing labeled content
Checking sensitive information matches
Filtering by location, label, workload, or information type
Validating whether classification results are accurate

This is especially useful before audits and migrations.

It gives the team evidence instead of guesswork.

Data Classification Content Viewer role

Content Explorer access must be handled carefully because it can expose sensitive information.

Microsoft separates access into role groups.

The two important role groups are:

Content Explorer List Viewer
Content Explorer Content Viewer

The List Viewer role allows a user to see classified items and their locations, but not open the content.

The Content Viewer role allows a user to open and read the actual file content.

This distinction is important.

A reporting analyst may only need list-level visibility.

A compliance investigator may need content-level access.

The Content Viewer role should be treated as a privileged role. Assign it only to named users who need it, log its use, and review membership regularly.

Do not give broad access just because someone is part of the compliance team.

Activity Explorer: seeing what happens to sensitive data

Content Explorer answers:

What sensitive data do we have?

Activity Explorer answers:

What is happening to that data?

Activity Explorer shows user and system activity related to sensitive and labeled content.

This can include actions such as:

Label applied
Label changed
Label removed
File shared externally
File downloaded
DLP rule matched
Sensitive content accessed

This is useful because classification is not only about inventory.

It is also about behavior.

A file marked Confidential is one thing.

Knowing that it was shared externally, downloaded to an unmanaged device, or had its label removed is far more useful for risk management.

Together, Content Explorer and Activity Explorer give admins both inventory and activity context.

Why classification matters before Microsoft 365 migration

Most Purview discussions focus on steady-state compliance.

But classification becomes even more important during tenant-to-tenant migration.

During migration, organizations often move:

Mailboxes
OneDrive accounts
SharePoint sites
Teams content
Groups
Planner data
Power Platform assets
Power BI content

If sensitive data is not classified before migration, the target tenant may inherit the same unmanaged risk from the source tenant.

A migration is a good opportunity to clean up, classify, archive, delete, and re-govern content before it lands in the new environment.

The goal is not just to move data.

The goal is to move the right data with the right protection.

Phase 1: Pre-migration discovery

Before moving content, run discovery in the source tenant.

A practical approach is to run Purview classification for at least a few weeks before migration planning is finalized.

During this phase:

Enable relevant built-in Sensitive Information Types
Add custom SITs for business-specific identifiers
Publish a small sensitivity label taxonomy
Use Content Explorer to find sensitive data locations
Identify high-risk SharePoint sites, OneDrive accounts, and mailboxes
Review external sharing and access patterns

This phase helps answer a key question:

What is the blast radius if this migration goes wrong?

Many organizations discover that most sensitive data is concentrated in a smaller number of sites, accounts, or shared mailboxes.

That discovery helps prioritize migration planning.

Phase 2: Cleanup and scoping

Once you know where sensitive data lives, decide what should happen to it.

Not everything should be migrated.

Some content should move.

Some should be archived.

Some should be deleted.

Some should be reviewed by business owners before any migration begins.

This is the right time to:

Remove stale content
Archive legacy data
Apply retention labels
Reduce oversharing
Fix ownership gaps
Confirm sensitivity labels
Define what content is out of scope

For existing content at rest, service-side auto-labeling is especially useful because it can classify SharePoint, OneDrive, and Exchange data in the background.

If you wait until after migration to label content, you may lose important chain-of-custody context.

Labeling at the source gives you better visibility before content moves.

Phase 3: Migration and label handling

Sensitivity labels need special planning during tenant-to-tenant migration.

Labels and encryption are often tied to the source tenant’s identities, policies, and protection configuration.

Because of this, labels do not always transfer cleanly across tenants.

In many migration scenarios, the practical approach is:

Move the content.
Preserve metadata, permissions, and version history where possible.
Recreate the label taxonomy in the target tenant.
Map source labels to target labels in the migration runbook.
Re-apply or validate labels in the target using Purview policies or scripted approaches.
Validate access behavior after cutover.

Before cutover, confirm these items:

The target tenant has the same or equivalent label taxonomy.
Source labels are mapped to target labels.
Files with user-assigned permissions are identified separately.
Auto-labeling policies in the target are scoped carefully.
Protected content is tested after migration.
Validation includes access behavior, not only file counts.

This is important because a migration that reports successful file counts may still fail from a compliance perspective if protection does not work correctly in the target tenant.

Phase 4: Post-migration validation

After migration, use Content Explorer and Activity Explorer in the target tenant to validate classification coverage.

Compare source and target results.

Look for gaps such as:

Missing labels
Incorrect label mapping
Files that lost metadata
Permissions that no longer match business rules
Sensitive content moved to unexpected locations
External sharing behavior that changed after migration

Plan a stabilization period after cutover.

For the first 30 days, review classification and activity reports weekly.

Migration projects often surface edge cases, such as:

Legacy files that were never classified
Service accounts that bypassed expected controls
Third-party connectors that changed metadata
Files protected in a way that does not map cleanly to the target tenant

Post-migration validation is where you prove that the data was not just moved, but moved safely.

Choosing the right data discovery and classification stack

Microsoft Purview is the right foundation for most Microsoft 365 environments.

But in real migration projects, Purview is usually one part of a larger stack.

A practical stack may include:

Microsoft Purview for classification, labels, DLP, and visibility
A Microsoft 365 migration tool for moving workloads and preserving metadata
Power BI or reporting tools for audit and governance dashboards
Security or compliance workflows for investigation and review

When evaluating tools, ask these questions:

Does the tool preserve Microsoft Information Protection metadata?
Does it support the workloads you actually use?
Can it handle SharePoint, OneDrive, Teams, Exchange, Planner, and Power Platform data?
Does it scale without creating throttling problems?
Does it produce audit evidence your compliance team can trust?
Does it support validation before and after migration?

The goal is not only migration completion.

The goal is governed migration completion.

A practical 30-day Purview classification checklist

If you are starting with Microsoft Purview classification, keep the first 30 days simple.

Here is a practical starting checklist:

Publish a small sensitivity label set.
Use clear label names that business users can understand.
Enable the built-in Sensitive Information Types that match your compliance needs.
Create one or two custom SITs for your internal identifiers.
Run auto-labeling in simulation mode first.
Review matches in Content Explorer before enabling enforcement.
Assign the Content Viewer role only to selected named users.
Review Activity Explorer weekly for the first month.
Document label ownership and escalation paths.
Use classification data to guide migration, audit, and AI-readiness planning.

Do not overcomplicate the first version.

A smaller label taxonomy that people actually use is better than a complex model nobody understands.

Final thoughts

Classification is not a one-time project.

It is an ongoing practice.

The organizations that handle migrations, audits, security reviews, and AI rollouts more smoothly are usually the ones that started labeling early.

They know where sensitive data lives.

They know who can access it.

They know which content should move, which content should stay, and which content should be retired.

Microsoft Purview gives Microsoft 365 admins the visibility and control needed to make that possible.

Start small.

Classify what matters.

Keep the label model simple.

Use Content Explorer and Activity Explorer regularly.

And if you are preparing for a Microsoft 365 tenant migration, do not wait until cutover to think about classification.

By then, it is already too late.

Teams Private Chat Migration: What to Do When Migration Tools Stop Supporting It

Apps4.Pro Migration Manager — Sat, 30 May 2026 07:29:49 +0000

When organizations plan a Microsoft 365 tenant-to-tenant migration, most attention goes to workloads like Exchange mailboxes, SharePoint, OneDrive, Teams channels, and user accounts.

But one area often becomes complicated very quickly: Microsoft Teams private chat migration.

As more migration tools reduce or remove support for migrating private chat history, many IT teams are discovering that preserving conversation data is harder than expected. Yet for many organizations, chat history still contains important business context that users rely on every day.

Why Private Chat History Still Matters

Private chats often contain information that is not stored anywhere else.

This may include:

Project decisions
Internal approvals
Customer escalation discussions
Troubleshooting history
HR or leadership conversations
Shared links and references
Context behind business decisions

If this data is not preserved during migration, users may lose access to important historical information after moving to the new Microsoft 365 tenant.

This can lead to:

Lost business context
Increased support tickets after migration
User dissatisfaction
Productivity loss
Compliance or retention concerns
Dependency on manual exports or screenshots

For many users, private chats contain the context behind projects, approvals, and technical decisions. Losing that history after migration can directly affect productivity.

Why Teams Chat Migration Is Becoming More Difficult

Migrating private conversations is very different from migrating Teams channels or SharePoint files.

Private chats are user-based conversations that require careful handling of:

Source and destination user mapping
Participant relationships
Message timestamps
Conversation order
Attachments and shared links
Permissions
Tenant configuration
Microsoft API limitations
Post-migration validation

If identity mapping is incorrect, conversations can lose context. If timestamps or participants are not preserved properly, migrated chats may become difficult for users to understand.

Because of these technical challenges, several migration tools have reduced or removed support for private chat migration scenarios.

The business need, however, has not disappeared.

Common Migration Scenarios Where Chat History Matters

Organizations still request private chat migration in scenarios such as:

Tenant-to-tenant migration projects
Mergers and acquisitions
Company rebranding
Tenant consolidation
Divestitures
Business unit separation
Compliance-driven migration projects

In these situations, users often expect their communication history to move with them.

Missing chat history after migration can reduce user confidence in the project and increase post-migration support requests.

Recommended Approach Before Migrating Teams Private Chats

Private chat migration should be treated as a dedicated planning area rather than a small optional task at the end of the migration project.

1. Identify Whether Chat Migration Is Really Required

Not every organization needs to migrate all private conversations.

Before selecting a migration approach, IT teams should identify:

Which users require chat history
Whether compliance or legal retention applies
Which departments depend heavily on Teams conversations
Whether full migration or selective migration is needed

This helps reduce unnecessary migration scope and complexity.

2. Validate User Mapping Carefully

Private chat migration depends heavily on accurate identity mapping between the source and destination tenants.

Correct mapping helps preserve:

Conversation ownership
Participant names
Message readability
User context
Access after migration

Incorrect mapping can reduce the value of migrated conversations significantly.

3. Run a Pilot Migration First

A pilot migration helps validate:

How migrated chats appear
Whether participants are mapped correctly
Whether timestamps remain readable
Whether conversation order is preserved
Whether users can access important discussions successfully

Pilot testing also helps IT teams communicate realistic expectations before full deployment.

4. Communicate Limitations Clearly

Private chat migration may still have limitations depending on APIs, permissions, tenant configuration, and message types.

Before migration, users should understand:

What data will be migrated
What may not be migrated
How migrated chats will appear
Whether attachments and links are included
Where migrated history can be accessed
Who to contact if issues appear

Clear communication reduces confusion after migration.

5. Use a Platform That Still Supports Chat Migration

As support becomes less common across migration tools, organizations may need to evaluate platforms that still support Teams private chat migration scenarios.

Some migration platforms, including Apps4.Pro Migration Manager, continue to support Teams private chat migration for organizations where preserving communication history remains important.

Best Practices for Teams Private Chat Migration

Before starting the migration:

Define the migration scope clearly
Identify critical users and departments
Review compliance and retention requirements
Validate source and destination user mapping
Run a pilot migration first
Review migration results before full rollout
Communicate expected outcomes to users
Maintain a fallback plan for critical conversations

These steps can help reduce migration risk and improve user experience after the move.

Conclusion

Teams private chat migration is becoming harder as more migration tools reduce or remove support for it. However, the requirement itself has not disappeared.

Organizations still rely on private chat history for business context, approvals, troubleshooting, customer communication, and collaboration history. Losing that information during a tenant-to-tenant migration can create productivity issues and increase post-migration support effort.

The best approach is to identify the requirement early, validate user mapping carefully, run pilot migrations, communicate limitations clearly, and choose a migration solution that supports the organization’s business needs.

Have you handled Teams private chat migration in a real Microsoft 365 migration project? What challenges or limitations did you encounter?

Power BI Migration Gaps: What Does Not Move Automatically and How to Handle It

Apps4.Pro Migration Manager — Thu, 28 May 2026 09:58:41 +0000

When planning a Power BI tenant-to-tenant migration, most teams focus on moving workspaces, reports, datasets, and dashboards.

But in real projects, that is only part of the story.

Some Power BI artifacts do not move automatically because they depend on tenant-specific settings, connections, capacities, security groups, gateways, or live endpoints.

Common examples include:

Power BI dataflows
Embedded and premium capacities
Paginated reports
Power BI Apps
Scorecards
Streaming datasets

If these items are not planned properly, reports may fail after migration, refreshes may break, and business users may lose access to important analytics experiences.

This article explains what typically does not migrate automatically and how to prepare for it.

1. Power BI Dataflows

Power BI dataflows are often difficult to migrate automatically because they are tightly connected to the source tenant environment.

A dataflow may depend on:

Power Query M logic
On-premises or cloud data gateways
Stored credentials
Parameters
Custom functions
Data source permissions
Refresh schedules
Downstream datasets and reports

Because of these dependencies, simply copying a dataflow to another tenant is usually not enough. The dataflow may open successfully but fail during refresh because credentials, gateways, or source references are no longer valid.

How to handle dataflow migration

A safer approach is to rebuild and validate dataflows in the target tenant.

Recommended steps:

List all workspaces that contain dataflows.
Identify business-critical dataflows first.
Document each dataflow owner, data source, refresh schedule, gateway, and dependency.
Export or copy the Power Query M logic from the source tenant.
Configure equivalent gateways, credentials, and data source permissions in the target tenant.
Recreate the dataflows in the target workspace.
Run test refreshes.
Compare row counts, sample outputs, and key measures with the source tenant.
Reconnect dependent datasets and reports to the new dataflows.
Keep the old dataflows until business users confirm that the new setup works correctly.

Dataflows should be migrated in small waves rather than all at once. This reduces risk and makes troubleshooting easier.

2. Embedded and Premium Capacity

Power BI embedded and premium capacity migration is not just about moving content. It also involves architecture, licensing, cost, performance, and governance.

During migration, capacity-related details usually change, such as:

Capacity assignment
Capacity region
SKU selection
Premium Per User usage
Premium Per Capacity usage
Fabric capacity decisions
Service principal access
Embedded application configuration
API permissions

If your organization uses embedded analytics, the migration may also affect application authentication, workspace binding, and capacity assignment.

How to plan capacity migration

Treat capacity migration as a separate workstream.

A practical checklist:

Map each workspace to its current capacity.
Identify workspace owners and business criticality.
Decide the target capacity model.
Review whether Premium Per User, Premium Per Capacity, or Fabric capacity is the best fit.
Plan for a coexistence period where both source and target tenants may run in parallel.
Rebind workspaces to the correct target capacity.
Validate embedded apps, service principals, APIs, and permissions.
Monitor performance after each migration wave.
Adjust capacity size or workload placement if required.

Capacity planning should happen early because it can affect both migration timelines and licensing cost.

3. Paginated Reports

Paginated reports require special attention because they are built differently from standard Power BI reports.

They are based on RDL files and are often used for:

Pixel-perfect reporting
Financial statements
Invoices
Operational reports
Export-ready PDF or Excel reports

These reports may depend on specific data sources, credentials, parameters, page layouts, and export settings.

Because of this, paginated reports are usually not migrated automatically as part of a normal Power BI content migration.

How to migrate paginated reports

Use a controlled manual process:

Create an inventory of all paginated reports.
Note each report owner, workspace, data source, and usage frequency.
Export the RDL files from the source environment or retrieve them from source control.
Configure matching data sources in the target tenant.
Update credentials and connection strings.
Upload or republish the reports into the target workspace.
Test parameters, filters, page layout, exports, and totals.
Ask business users to validate the final output.

For paginated reports, visual accuracy matters. Always validate exports such as PDF, Excel, and printed layouts before completing the migration.

4. Power BI Apps

Power BI Apps are curated experiences that package reports, dashboards, and navigation for a specific audience.

They usually include:

Audience targeting
Navigation structure
Report grouping
Permissions
Security groups
Workspace connections

During tenant migration, the audience configuration and security groups usually change. Because of this, Power BI Apps generally need to be recreated and republished in the target tenant.

How to recreate Power BI Apps

Before migration:

Capture the current app layout.
Document included reports and dashboards.
Note navigation order and sections.
Map source security groups to target Microsoft Entra ID groups.
Identify app owners and publishers.

After migration:

Recreate the app in the target tenant.
Rebuild audience settings.
Validate permissions.
Publish the app to a pilot group.
Roll it out to all users after confirmation.

This helps avoid broken access after migration.

5. Scorecards

Power BI scorecards are used to track metrics and business goals. They may depend on linked datasets, owners, thresholds, check-ins, and alerts.

These dependencies are usually tenant-specific, so scorecards may not migrate cleanly through automated tools.

How to handle scorecards

Recommended approach:

Document all scorecards before migration.
Capture metric definitions, owners, thresholds, and status rules.
Identify linked datasets and reports.
Recreate scorecards in the target tenant.
Reconnect them to the correct datasets.
Reconfigure alerts and permissions.
Ask business users to validate the metrics.

Scorecards should be reviewed with business owners because they often represent executive or operational KPIs.

6. Streaming Datasets

Streaming datasets are another area that requires careful planning.

They may receive data from:

IoT devices
Custom applications
Power Automate flows
APIs
Event-driven pipelines
Real-time monitoring systems

During migration, streaming dataset endpoints and connection strings usually change. If producers continue sending data to the old endpoint, the new reports will not receive live data.

How to migrate streaming datasets

To reduce downtime:

List all streaming datasets.
Identify the systems or applications that send data to them.
Recreate streaming datasets in the target tenant.
Generate new endpoints or connection details.
Update producers, APIs, applications, or pipelines.
Test live data ingestion.
Confirm dashboard visuals are updating correctly.
Retire the old endpoints only after validation.

For real-time dashboards, plan a cutover window and communicate it clearly to users.

Summary Checklist

Here is a quick checklist for Power BI migration gaps:

Artifact	Migration Concern	Recommended Action
Dataflows	Gateways, credentials, Power Query logic	Rebuild and validate in target tenant
Embedded/Premium Capacity	Capacity, licensing, region, APIs	Plan as a separate workstream
Paginated Reports	RDL files, layouts, data sources	Export, republish, and test manually
Apps	Audiences, permissions, navigation	Recreate and republish
Scorecards	Metrics, owners, alerts, linked datasets	Document and recreate
Streaming Datasets	Live endpoints and producers	Recreate endpoints and update producers

Final Thoughts

A successful Power BI tenant-to-tenant migration is not only about moving reports and datasets.

Dataflows, paginated reports, apps, scorecards, streaming datasets, and capacity configurations all need specific planning. These items often fail because they depend on settings that are unique to the source tenant.

The best approach is to identify these gaps early, create a migration checklist, test each artifact type separately, and involve business owners before final cutover.

By treating these items as dedicated migration workstreams, you can reduce downtime, avoid broken reports, and give users a smoother Power BI experience in the new tenant.

Viva Engage Communities Are Coming to Microsoft Teams: What Admins and Organizations Should Know

Apps4.Pro Migration Manager — Fri, 22 May 2026 10:02:13 +0000

Viva Engage communities are becoming available inside Microsoft Teams as a native experience. This means your communities, conversations, leadership updates, and company-wide discussions can now live closer to where employees already collaborate every day.

Instead of switching between Teams and Viva Engage, users will be able to discover, follow, and participate in community conversations directly from the Teams interface.

For organizations, this is a big step toward bringing employee engagement, internal communication, and knowledge sharing into the flow of work.

What is changing?

Microsoft is bringing Viva Engage communities into Microsoft Teams so employees can access community conversations from the same place they use for chats, channels, meetings, and collaboration.

Community notifications can also appear in the Teams activity feed, helping important updates become part of daily work instead of becoming “one more app to check.”

The new experience supports two main layouts:

Unified view

Communities appear as a section inside the Chat experience. This allows chats, group chats, and communities to appear in one familiar list.

Split view

Communities appear as a separate section alongside chats and channels. This keeps communities visible while still separating them from regular team collaboration spaces.

In both experiences, existing Viva Engage memberships are synced automatically. Favorites are carried over, and notifications can take users directly back to the right community in Teams.

Key capabilities of Viva Engage Communities in Teams

The new Viva Engage experience in Teams is not only a shortcut. It introduces a more connected way for users to find communities, post updates, and stay engaged.

Some of the key capabilities include:

Find your communities

Users can view their top communities and browse the communities they already belong to directly from Teams.

Organize important communities

Users can favorite key communities and leave communities they no longer need, helping keep the experience focused and relevant.

Create posts from Teams

Users can start discussions, ask questions, share praise, create polls, and publish announcements from inside a community.

Post or comment as a delegate

When delegate permissions are assigned, users can post or reply on behalf of leaders or teams.

Manage activities and notifications

Viva Engage updates can appear in the Teams activity feed. Users can also adjust notification preferences based on how they want to stay informed.

Search communities and conversations

Users can search for communities and search within a community to find specific posts, replies, or discussions.

View community analytics

Community owners, admins, and communicators can track engagement using analytics such as active members, posts, and activity trends.

Access community events

Users can view upcoming, live, and past events from the Events tab and join sessions or watch recordings from the community.

Together, these features make Viva Engage Communities in Teams a more practical place for employees to connect, learn, and participate without leaving their daily workspace.

What admins need to know

For Microsoft 365 and Teams admins, this change is important because the experience depends on the right access, settings, and rollout approach.

Here are the key admin actions to review:

Make sure Viva Engage is not blocked at the network level.
Confirm that users are allowed to sign in to Viva Engage through Microsoft Entra ID.
Verify that users have the required Microsoft 365, Teams, and Viva Engage access.
Use the Microsoft Teams admin center to manage whether Viva Engage experiences in Teams are enabled.
Decide whether to pilot the experience first or roll it out broadly.
Choose whether unified view or split view is better for your organization.

A phased rollout is usually the safer approach. Start with a pilot group, collect feedback, and then expand to more users once navigation, notifications, and community ownership are clear.

Use IT office hours to support adoption

This rollout is a good opportunity for IT teams to support adoption instead of only enabling a feature.

One practical idea is to create or refresh an “Ask IT” or “Digital Workplace Help” community.

You can use this community to:

Answer user questions during weekly office hours.
Pin helpful answers and short guides.
Share quick tips about using Viva Engage in Teams.
Collect feedback from early users.
Reduce repeated support questions.

This approach helps employees understand the new experience while also building trust with IT and internal communication teams.

Add Viva Engage to Teams channels

Viva Engage is not limited to the main Communities entry point in Teams. You can also add Viva Engage as a tab inside a Teams channel.

This is useful when a specific team needs quick access to a broader community or topic.

For example:

HR teams can pin a People and Culture community.
Sales teams can pin a Customer Wins community.
Engineering teams can pin a Dev Practices topic.
Regional teams can pin location-specific communities.

When adding Viva Engage as a tab, make sure you explain why the tab exists and how the team should use it. Otherwise, users may see it as another unused tab.

Quick rollout checklist

Before rolling out Viva Engage Communities in Teams, review this checklist:

Confirm Viva Engage access and licensing for your target users.
Decide whether unified view or split view is the best fit.
Run a pilot with a small group of users.
Collect feedback on navigation, notifications, and usefulness.
Identify core communities such as company news, leadership updates, HR help, communities of practice, social groups, DEI spaces, and regional hubs.
Publish simple guidance for community owners.
Review existing Viva Engage or Yammer networks.
Identify whether tenant-to-tenant migration or network consolidation is required.
Use a dedicated migration approach instead of relying only on manual exports.

Why migration planning matters

Microsoft provides the integrated Teams experience, but organizations are still responsible for managing their Viva Engage data, communities, and migration strategy.

If your organization has multiple tenants, legacy Yammer networks, or communities spread across environments, you may need a proper migration and consolidation plan before promoting Viva Engage in Teams.

This is where Apps4.Pro Migration Manager can help.

With Apps4.Pro, organizations can:

Perform tenant-to-tenant Viva Engage migrations.
Consolidate Viva Engage or Yammer networks.
Move communities, members, conversations, likes, best answers, mentions, and tags.
Migrate connected files from SharePoint and legacy Yammer storage.
Run migrations in controlled waves.
Monitor migration progress.
Validate results before directing users to the new Teams experience.

Final thoughts

Viva Engage Communities in Microsoft Teams can make employee engagement more visible, accessible, and connected to daily work.

But the success of this experience depends on more than simply enabling the feature. Admins and communication teams should plan the rollout, prepare community owners, guide users, and review whether migration or consolidation is required.

If your organization is preparing for Viva Engage in Teams, now is the right time to clean up communities, review legacy Yammer networks, and make sure your engagement data is ready for the next experience.

Exchange Online Mailbox Migration Between Microsoft 365 Tenants: Key Things to Know

Apps4.Pro Migration Manager — Wed, 20 May 2026 12:19:43 +0000

Migrating Exchange Online mailboxes between Microsoft 365 tenants is not just about moving emails from one place to another.

A mailbox contains much more than messages. It can include calendar events, contacts, tasks, inbox rules, mailbox permissions, archive content, and compliance-related settings. If these areas are not planned properly, users may face missing access, broken rules, failed replies, or incomplete mailbox functionality after migration.

This guide explains the major areas organizations should review before starting an Exchange Online tenant-to-tenant mailbox migration.

Why Exchange Online Mailbox Migration Is Complex

At first, mailbox migration may sound simple: move the mailbox from the source tenant to the target tenant.

In reality, the challenge is not only the mailbox data. The bigger challenge is preserving the surrounding configuration that makes the mailbox usable.

For example, users may depend on:

Delegated mailbox access
Send As and Send on Behalf permissions
Inbox rules
Shared mailboxes
Online archive mailboxes
Retention policies
Calendar data
Microsoft To Do tasks
Reply and Reply All behavior after domain changes

If these dependencies are missed, the migrated mailbox may exist in the target tenant, but users may still experience issues.

Common Reasons for Tenant-to-Tenant Mailbox Migration

Organizations usually perform Exchange Online mailbox migration during major business or IT changes.

Common scenarios include:

Mergers and acquisitions
Company divestitures
Microsoft 365 tenant consolidation
Rebranding or domain changes
Compliance-driven tenant restructuring
Moving users from one Microsoft 365 environment to another

Each scenario can introduce different risks, especially when usernames, domains, or identities change during the migration.

Prerequisites Before Migration

Before starting the mailbox migration, the target tenant must be prepared properly.

Important prerequisites include:

Creating matching MailUser objects in the target tenant
Establishing an organization relationship between source and target tenants
Configuring the required application registration and permissions
Assigning the correct Exchange Online licenses
Planning DNS and domain verification
Preparing user and mailbox mapping
Reviewing archive mailbox requirements

If the domain is moving from one tenant to another, the cutover must be planned carefully because a domain can only be verified in one Microsoft 365 tenant at a time.

What Usually Migrates

In a typical Exchange Online tenant-to-tenant migration, the following mailbox data can be migrated:

Inbox, Sent Items, Drafts, and custom folders
Emails and attachments
Calendar items
Contacts
Tasks and notes
Server-side inbox rules
Mailbox permissions, when properly mapped
Archive mailboxes, when enabled and licensed in the target tenant

However, admins should not assume that every mailbox-related setting will move automatically.

What May Not Migrate Automatically

Some items may not migrate or may require separate handling.

Examples include:

Client-side Outlook rules
Transport rules
Retention tags and MRM policies
Meeting response tracking metadata
OneDrive-linked attachment URLs
Some app-layer Microsoft To Do features
Permissions that are not properly mapped
Items blocked by size limits

This is why a migration checklist is important. It helps avoid surprises after cutover.

Inbox Rules Need Special Attention

Inbox rules are often overlooked during mailbox migration.

Server-side rules may migrate, but they can break if folder paths, recipient addresses, or target-domain mappings are not correct.

Client-side rules are different. These rules depend on Outlook and local client behavior, so they usually need to be recreated manually.

Admins should review:

Server-side rules
Client-side rules
Rules that forward or redirect messages
Rules that move messages to folders
Rules using old recipient addresses
Rules affected by domain changes

After migration, users should test important rules to confirm they still work.

Cross-Domain Migration and Reply Issues

Cross-domain migration can create additional issues.

For example, a user may move from:

*john.doe@companyA.com *
to:

jdoe@companyB.com

If old addresses remain inside message headers, calendar items, or rules, Reply and Reply All actions may still point to outdated addresses.

This can cause replies to fail or route incorrectly.

For migrations involving domain and username changes, admins should plan address mapping carefully and validate reply behavior after migration.

Mailbox Permissions Matter

Mailbox permissions are one of the most important parts of an Exchange Online migration.

Many organizations rely on delegated access for daily work. For example:

Executive assistants managing executive mailboxes
Support teams using shared mailboxes
Finance users accessing billing mailboxes
HR teams managing recruitment or employee communication mailboxes

Important permission types include:

Full Access
Send As
Send on Behalf
Folder-level permissions

If these permissions are not migrated or reassigned correctly, business users may lose access after cutover.

Admins should export permissions before migration, map users correctly, and validate delegated access in the target tenant.

Shared Mailbox Migration

Shared mailboxes are commonly used by teams for addresses such as:

support@
billing@
sales@
hr@
info@

These mailboxes are important because multiple users may depend on them every day.

When migrating shared mailboxes, admins should confirm:

The mailbox exists in the target tenant
Required permissions are preserved or reassigned
Send As and Send on Behalf permissions work
Members can access the mailbox
Mail flow works after cutover
Licensing requirements are understood

Shared mailbox migration should be tested carefully because it can affect entire departments, not just individual users.

Archive Mailbox Migration

Archive mailboxes require separate planning.

A user’s primary mailbox and archive mailbox may have different size, licensing, and performance considerations. Archive mailboxes must be enabled in the target tenant, and the correct license must be assigned.

Admins should review:

Whether the source mailbox has an archive
Archive mailbox size
Target tenant licensing
Auto-expanding archive requirements
Migration performance
Post-migration archive access

Archive migration is often missed during planning, but it can become a major issue for users who rely on historical email data.

Retention Policies and Compliance

Retention policies do not always move cleanly between tenants.

Organizations may be moving from older Exchange retention methods to Microsoft Purview retention. This requires careful compliance planning.

Admins should review:

Existing MRM retention tags
Personal retention tags
Microsoft Purview retention policies
Legal hold or compliance requirements
Deletion and archive behavior
User communication needs

Retention settings should be reviewed before migration, not after users report missing or unexpected email behavior.

Microsoft To Do and Mailbox Migration

Microsoft To Do is closely connected to Exchange Online because many tasks are stored as Outlook tasks inside the mailbox.

Core task data may move with the mailbox, such as:

Task titles
Due dates
Reminders
Categories
Attachments

However, some Microsoft To Do app-level features may not migrate in the same way, such as list sharing, checklist steps, custom ordering, or My Day history.

Users who rely heavily on Microsoft To Do should be informed about possible limitations before migration.

EWS Retirement and Migration Planning

Another important consideration is the future of Exchange Web Services.

Microsoft is moving away from EWS, and migration tools that still depend on EWS need to plan for Microsoft Graph support. The original Apps4.Pro guide notes that EWS will be disabled by default on October 1, 2026, and permanently removed by April 1, 2027.

This is important for long-term migration planning. If your organization has large migrations scheduled around or after this period, confirm whether your migration tools support Graph API.

Post-Migration Validation Checklist

After migration, do not stop at confirming that the mailbox exists in the target tenant.

Admins should validate the full user experience.

A practical checklist includes:

User can access the mailbox
Emails and folders are available
Calendar items are present
Contacts are available
Tasks are available
Server-side rules work
Delegated permissions work
Send As and Send on Behalf work
Shared mailbox access works
Archive mailbox is accessible
Retention behavior is correct
Reply and Reply All work with the new domain
Mobile and Outlook clients are reconfigured if needed

Validation should include both IT testing and business-user confirmation.

Best Practices for Exchange Online Tenant Migration

To reduce risk, follow these best practices:

Start with a full mailbox inventory
Identify shared and archive mailboxes early
Export mailbox permissions before migration
Map users and domains carefully
Review server-side and client-side rules
Prepare target tenant licenses in advance
Plan domain cutover timing
Communicate known limitations to users
Test pilot users before large migration waves
Monitor mail flow and mailbox access after cutover

A phased approach is usually safer than moving everything at once.

Final Thoughts

Exchange Online mailbox migration between Microsoft 365 tenants requires more than mailbox data transfer.

A successful migration must also account for permissions, rules, shared mailboxes, archive mailboxes, retention policies, Microsoft To Do tasks, domain changes, and future API changes such as EWS retirement.

The best approach is to plan early, document every dependency, test with pilot users, and validate the user experience after migration.

When these steps are handled properly, organizations can reduce disruption and give users a smoother transition to the new Microsoft 365 tenant.

Original Source

This article was originally published on Apps4.Pro:

Exchange Online Mailbox Migration Guide