DEV Community: Apps4.Pro Migration Manager

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