Power Platform ALM Using Native Pipelines: Step-by-Step Dev to Prod Deployment Guide

Introduction

Application Lifecycle Management (ALM) is critical for building reliable, scalable Power Platform solutions. A proper ALM setup ensures that changes are developed safely, tested thoroughly, and deployed consistently into production.

Microsoft Power Platform Pipelines provide a native CI/CD automation approach to deploy Power Platform solutions across environments while maintaining governance, traceability, and consistency.

This article covers a complete Power Platform ALM implementation using native Power Platform Pipelines.

Below, we'll configure Power Platform Pipelines for a standard Dev → Test → Prod setup and walk through deploying a solution across environments.

Prerequisites

Before starting, make sure you already have:

1. Three Power Platform environments configured:
   • Development (Sandbox - Unmanaged Solutions)
   • Test (Sandbox - Managed Solutions)
   • Production (Managed Solutions)
2. All environments use Dataverse
3. You have Power Platform admin access
4. You have a sample or real solution in the Dev environment

Before You Begin

This guide assumes that at least one solution already exists in your Development environment for deployment validation.

If not, create a new solution and add one or more Power Platform components such as:

• A Canvas or Model-driven Power App
• A Power Automate flow
• A Copilot agent
• A Dataverse table

This solution will be used to validate your Dev → Test → Prod deployments using pipelines.

We’ll refer to this as the example solution throughout the guide.

Setting Up the Power Platform Pipelines Host Environment

Power Platform Pipelines require a dedicated host environment where pipeline configurations, deployment stages, and execution are stored and managed.

This is typically a Production-type environment with Dataverse enabled, dedicated to managing pipeline configurations and execution.

Step 1: Create the Host Environment

1. Go to Power Platform Admin Center → https://admin.powerplatform.com
2. Navigate to Manage → Environments. And click “New”

Use these settings:

• Name: Power Platform Pipelines Host
• Managed: No
• Type: Production
• Add Dataverse: Yes
• URL: companyname-pp-host

Once created, wait for provisioning to complete. Once it’s in Ready state, start with Step 2.

Step 2: Install Power Platform Pipelines App

1. In Admin Center, go to Manage → Dynamics 365 Apps
2. Find Power Platform Pipelines
3. Click Install



4. Select the Host Environment
5. Install

After installation, you’ll see a model-driven app named “Deployment Pipeline Configuration” in the Power Platform Pipelines Host environment. This is where all pipelines are managed.

Step 3: Grant Permissions to the Existing Service Account

A service account typically holds elevated privileges such as the System Administrator role. Although Power Platform Pipelines can run under a personal user account, using a dedicated service account is a recommended best practice to ensure continuity, improve security, and avoid granting elevated permissions to individual users in target environments.

In this guide, we assume your organization already has a dedicated service account for automation and integrations.

Required Permissions

The service account must have System Administrator access in all environments involved in the pipeline:

• Development
• Test
• Production
• Pipelines Host environment

How to Assign Roles

In each environment:

1. Open Power Platform Admin Center
2. Select the environment and go to “Users -> See all”



3. Select the service account from the list of users
4. Assign the System Administrator security role

Repeat this for all environments: Dev, Test, Prod, and Host.

Step 4: Register Environments in the Pipelines App

Open the Deployment Pipeline Configuration app in the host environment.

Register Development Environment

1. Go to Environments → New

1. Fill in:
   • Name: ALM (Dev)
   • Type: Development
   • Owner: You
   • Environment ID: Copy from Development Environment Landing Page

1. Save and wait for validation = Success

Register Target Environments

Repeat the same process for:

Test

• Name: ALM (Test)
• Type: Target

Production

• Name: ALM (Prod)
• Type: Target

Step 5: Create a Pipeline

Open the Deployment Pipeline Configuration app in the host environment.

1. Go to Pipelines, Click New

1. Name: ALM Pipeline
2. Enable: Allow redeployments of older versions
3. Save

Link the Development Environment

Add Development Environment as the source environment to the created pipeline.

Add Deployment Stages

Click New Deployment Stage:

Test Stage

• Name: Deployment to Test
• Target: Test Environment

Production Stage

• Name: Deployment to Prod
• Previous Stage: Test
• Target: Production Environment

Now, we can see both stages in the Deployment Stages section:

Assign Security Roles

Open Security Teams in the Pipelines app.

Pipeline Admins

Add users who are allowed to configure pipelines. This will allow added users to access the deployment pipeline configuration app, add new pipelines, and edit existing pipelines in the host environment.

• Navigate to Deployment Pipeline Administrators
• Click Add existing user

• Search for the required user and add them

Pipeline Users

Add users who are allowed to run deployments.

• Navigate to Deployment Pipeline Users
• Click Add existing user

• Search for the required user and add them

Step 6: Deploy Power Platform Solution to Test Environment Using Pipelines

As we have created the Power Platform pipeline, we can deploy the solution from the Development environment to the Test (Staging) environment using the pipeline. Once it is successfully validated in the Test (Staging) environment, the solution can then be deployed to the Production environment.

• Go to Development Environment
• Open your example solution

• Click Pipelines

• Select your pipeline, and click Deploy here (Test/Staging stage)

• Select Now (or you can select Later to schedule the deployment) and click Next

• Verify the connections and resolve errors if any

• Verify the environment variable values and update them as needed

• Verify the Deployment Notes, modify as needed and click Deploy

• Wait for a few minutes to have the deployment completed. It appears as shown in the screenshot below when deployment is completed

Verify solution appears as Managed in Test (Staging) Environment

• Go to Test (Staging) Environment and the deployed solution should appear here

• Perform functional validation of the solution in the Test (Staging) environment.

Step 7: Deploy Power Platform Solution to Production Environment

Once testing is completed on the staging environment, we can deploy the same solution to production environment using the created pipeline.

• Go to Development Environment, open your example solution, go to pipelines
• Select your pipeline, and click Deploy here (Production stage)

• Then, follow the same steps we followed to deploy to Test (Staging) Environment

 

Verify solution appears as Managed in Production Environment

• Go to Production Environment and the deployed solution should appear here

• Perform final validation of the solution in the Production environment.

Conclusion

Implementing Power Platform ALM using native Pipelines simplifies deployment automation, improves governance, and ensures consistent solution delivery across environments. By following a structured Dev → Test → Prod approach, organizations can reduce deployment risks while accelerating release cycles.

Best Practices for Power Platform ALM Using Pipelines

• Keep Development solutions unmanaged for flexibility
• Always deploy managed solutions to Test and Production
• Use service accounts for pipeline execution
• Maintain environment variables per environment
• Validate deployments in staging before production release

If you need assistance implementing Power Platform ALM or automating enterprise deployments, feel free to contact our SharePoint & Power Platform consulting team here.

Introducing Heft: The Modern Build Tool Replacing Gulp in SharePoint Framework (SPFx)

For a long time, Gulp was the default build tool for SharePoint Framework (SPFx) projects. Developers relied on familiar commands like gulp serve and gulp bundle to compile, package, and deploy their SPFx solutions.

However, as SPFx applications grew in size and complexity, the traditional Gulp-based build system began to struggle with performance, scalability, and long-term maintainability.

To address these challenges, Microsoft introduced Heft - a modern build orchestrator from the Rush Stack ecosystem - and made it the default SPFx build tool starting with SPFx v1.22.

In this article, we’ll explore the differences between SPFx Heft vs Gulp, why Microsoft made the switch, and how Heft improves the modern SharePoint Framework development workflow.

The Gulp Era in SharePoint Framework (SPFx)

In the early days, Gulp handled almost everything in an SPFx project:

• Compiling TypeScript
• Bundling with Webpack
• Running the local dev server
• Packaging .sppkg files
• Automating the build pipeline

Typical workflows looked like this:

gulp serve
gulp bundle --ship
gulp package-solution --ship

For small projects, this worked fine. For large, long-living enterprise solutions, it did not.

Why Gulp Started to Fail

1. Slow Builds at Scale: Gulp runs tasks mostly sequentially, lacks smart caching, and often triggers full rebuilds for small changes. Result: Slow feedback loops and reduced productivity.

2. Fragile gulpfile.js: Task chains become complex, hard to debug, and frequently break during SPFx upgrades. Result: Build scripts harder to maintain than the app.

3. Poor Fit for Monorepos & Enterprise: Gulp wasn’t designed for monorepos, sharing build logic was painful, and dependency conflicts were common. Result: Scaling SPFx across teams became difficult.

4. Weak Type Safety & Debugging: Mostly JavaScript-based with unclear errors and poor traceability across tools. Result: Developers spent more time debugging the toolchain than writing features.

Enter Heft: The Modern SPFx Build Tool

Heft is a modern build orchestrator from Microsoft’s Rush Stack team, built to support large, enterprise-scale TypeScript solutions.

Unlike Gulp, which is a general-purpose task runner, Heft understands how modern development tools relate to one another - including TypeScript, ESLint, Jest, and Webpack.

Heft focuses on:

• Clearly defined build phases
• Plugin-based architecture
• Incremental builds and smart caching
• Parallel execution where possible

SPFx internally uses Heft to handle:

• Compilation
• Bundling
• Linting
• Testing
• Packaging

SPFx Workflow Update: With SPFx v1.22, Gulp is replaced by Heft - but the developer experience remains familiar.

Task	Command
Dev Server	heft start
Production Build	heft build --production
Package	heft package-solution --production

These commands are mapped to standard npm scripts (npm start, npm run build), so day-to-day development workflows remain unchanged.

SPFx Heft vs Gulp: What Actually Changed?

Feature	Gulp	Heft
Build approach	Scripted tasks	Phase-based orchestration
Performance	Slower at scale	Faster with caching & parallelism
Configuration	gulpfile.js	JSON-based configs
Type safety	Limited	Strong
Monorepo support	Weak	Built-in
Debugging	Hard to trace	Clear errors & logs

Deployment: What Did NOT Change

The deployment process remains exactly the same:

• Output is still a .sppkg file
• Deployment still happens via:
• SharePoint App Catalog
• CI/CD pipelines (Azure DevOps, GitHub Actions)

Only the build engine changed - not the deployment process.

Node.js & SPFx Compatibility

• SPFx v1.21.1+ → Node.js 22 LTS
• Older SPFx → Node.js 16 / 18
• SPFx ≤ 1.21 uses the Gulp-based toolchain
• Heft becomes the default starting from SPFx 1.22

Heft officially replaces Gulp starting with SPFx 1.22 onward.

Why Heft Actually Matters

Moving to Heft brings real, practical benefits:

• Faster rebuilds
• Less configuration code
• Fewer breaking changes
• Consistent builds across teams

Less time fighting the build system, more time writing features.

Frequently Asked Questions (FAQs)

What is Heft in SharePoint Framework (SPFx)?

Heft is a modern build orchestrator developed by Microsoft’s Rush Stack team. It replaces the traditional Gulp-based build system in SharePoint Framework (SPFx) starting from version 1.22, providing faster builds, better scalability, and improved developer experience.

Why did Microsoft replace Gulp with Heft in SPFx?

Microsoft replaced Gulp with Heft to improve performance, maintainability, and scalability of SPFx projects. While Gulp worked well for smaller solutions, it struggled with large enterprise applications. Heft introduces incremental builds, parallel execution, and modern tooling integration.

Is Gulp still used in SPFx projects?

Yes, older SPFx versions (up to 1.21) still use the Gulp-based build system. Starting from SPFx version 1.22, Heft is the default build tool for all new and updated projects.

Does Heft change the SPFx deployment process?

No. The deployment process remains unchanged. Developers still generate .sppkg files and deploy them through the SharePoint App Catalog or automated CI/CD pipelines such as Azure DevOps and GitHub Actions.

Which Node.js version should be used with Heft in SPFx?

SPFx version 1.21.1 and later support Node.js 22 LTS, while older SPFx versions typically rely on Node.js 16 or 18 depending on compatibility.

Final Thoughts

Gulp served SPFx well in its early days, but modern enterprise needs demanded something better.

Heft is not just a replacement, it’s an upgrade.

The shift from Gulp to Heft reflects Microsoft’s move toward a faster, and more scalable build system for SharePoint Framework projects.

If you have any questions, reach out to our SharePoint Consulting team here.

A Complete Step-by-Step Guide to Google Workspace to Microsoft 365 Email Migration

Introduction:

This blog describes an email migration from Google Workspace to Microsoft 365, focused exclusively on transitioning Gmail mailboxes to Exchange Online. The migration involved precise user-to-user mailbox mapping, preservation of primary SMTP addresses, and configuration of email aliases to ensure uninterrupted mail flow across multiple domains.

A phased, domain-based migration approach was used to reduce risk, validate mail delivery, and maintain identity consistency during cutover, providing a practical reference for executing real-world Google Workspace to Microsoft 365 email migrations.

Note: This article focuses on email migration.

To migrate files and folders, refer to this guide for Google Drive to OneDrive for Business (ODFB) migration.

Adding Domain in Microsoft 365 Account

Step 1: Access the Microsoft 365 Portal

Begin by navigating to office.com in your web browser. Sign in using your Global Administrator credentials to access the main dashboard.

Step 2: Launch the Admin Center

From your Microsoft 365 Home dashboard, locate the Admin tile (usually found under "Quick access" or by clicking the app launcher) and click it to enter the management portal.

Step 3: Access Domain Management

Inside the Admin Center, locate the left-hand navigation menu. Click on Settings to expand the list, then select Domains. This is where you will configure and verify the external domain you wish to migrate from Google Workspace.

Step 4: Initiate the Add Domain Wizard

In the Domains management pane, look for the toolbar at the top of the list. Click on the + Add domain button to begin the wizard. This will launch the setup process for linking your existing Google Workspace domain (e.g., yourcompany.com) to your Microsoft 365 tenant.

Step 5: Input Your Domain Name

The Add a domain wizard will now appear. In the designated text field, type the exact name of the domain you are migrating from Google Workspace (e.g., yourcompany.com). Once entered, click the Use this domain button to proceed to the verification stage.

Step 6: Verify Domain Ownership

Microsoft must confirm that you own the domain before proceeding. You will be presented with a few verification options. The most common and secure method is to select Add a TXT record to the domain's DNS records. Select this option and click Verify (or continue) to retrieve the specific record values you need to add to your DNS host.

Step 7:  Defer the DNS Connection

The wizard will now ask how you want to connect your domain. Since this is a migration and you are not ready to switch mail flow (MX records) yet, it is crucial to select Skip and do this later. This prevents any immediate disruption to your current Google Workspace emails. Click Continue to finalize the setup without altering your DNS.

Step 8: Finalize the Domain Setup

You will now see a confirmation screen stating, "Domain setup is complete." This indicates that Microsoft 365 has successfully verified your domain ownership. Since we chose to skip the DNS record updates for now (to keep your current email active), simply click the Done button to close the wizard.

Note: Once you click the Done button, your new domain will appear in the active domains list. It may also be automatically set as your Default domain for new user creation.

Provisioning Users for Microsoft 365 Migration

Step 9: Access User Management

In the Microsoft 365 Admin Center, locate the left-hand navigation pane. Click on Users to expand the menu, then select Active users. This dashboard is where you will create the destination accounts for your migration.

Step 10: Initiate User Creation

On the Active user's page, you will see the management dashboard for your user accounts. To start provisioning a new user, click the Add a user button located in the toolbar at the top of the list.

Step 11: Enter Basic User Details

The Add a user wizard will open to the Basics tab. Here, you must fill in the user's identity information, including First name, Last name, and Display name.

Step 12: Assign Product Licenses

On the Product licenses page, first select the appropriate country from the Location dropdown menu. Next, ensure the Assign user a product license option is selected. Check the box next to the specific license you wish to assign (e.g., Microsoft 365 Business Standard) and click Next.

Step 13: Configure Optional Settings

You will arrive at the Optional settings page. Here, you can assign specific administrative Roles to the user if needed, such as "Global admin" or "User admin". For a standard user, you can leave the default role ("User: no administration access") and click Next to proceed.

Step 14: Review and Finalize

You will now reach the Review and finish page. This is your chance to verify all the details you have configured, including the display name, username, and assigned licenses. If everything looks correct, click the Finish adding button to officially create the user account.

Step 15: Confirmation of User Creation

After a few seconds of processing, a confirmation window will appear stating "User added to active users." This indicates the account has been successfully created. You can view or copy the password details here if needed. Once done, click the Close button to exit the wizard.

Note: You must repeat these steps for every single active user you intend to migrate. Ensure all accounts are created and assigned valid licenses before proceeding to the migration phase.

Once all users are added, remember to set your custom domain as the Default. To do this, navigate to Settings > Domains in the Admin Center, select your new domain, and choose Set as default.

Migrating Google Workspace Mailboxes to Microsoft 365

Step 16: Access the Exchange Admin Center

In the Microsoft 365 Admin Center, locate the left-hand navigation menu. Click on ... Show all to expand the full list of options. Scroll down to the "Admin centers" section and select Exchange. This will launch the modern Exchange Admin Center (EAC) where the migration will be managed.

Step 17: Initiate a New Migration Batch

In the Exchange Admin Center dashboard, locate the Migration option in the left-hand navigation pane. Click it to open the migration management screen. From the top menu bar, select Add migration batch to launch the configuration wizard.

Step 18: Define Batch Name and Path

The Add migration batch wizard will open. First, enter a unique name for your migration (e.g., "GWorkspace_Migration") in the Migration batch name field. Next, locate the Select the mailbox migration path dropdown menu and choose Migration to Exchange Online. Click Next to proceed.

Step 19: Select Migration Type

On the Migration type screen, you will be presented with several options. Select Google Workspace (Gmail) migration from the list to specify the source environment. Click Next to continue to the prerequisites check.

Step 20: Configure Migration Prerequisites

The Prerequisites for Google Workspace migration window will now appear. You must choose how to prepare your Google Workspace environment for the data transfer. You have two options:

• Automate the configuration: Let Microsoft 365 handle the setup automatically (Recommended).
• Manually configure: Upload your own JSON key file and configure settings manually (Advanced).

 

Automate the Configuration of Your Google Workspace for Migration

Step 21: Initiate Automated Configuration

Under the Automate the configuration of your Google Workspace for migration section, click on the Start button. This will trigger the automated setup process which handles the necessary permissions and API connections for you.

Important Requirement: Before proceeding, ensure you have the Super Admin credentials for the Google Workspace tenant you are migrating from. The automated configuration tool requires these elevated privileges to establish the necessary connections and permissions.

Step 22: Retrieve Client ID, Scopes, and Private Key

Once the automation process finishes, the wizard will display your client ID and the required API Scopes. A direct link will also be provided to the Google Workspace Admin console, where you must add these scopes to authorize the connection.

Important: A Private Key (JSON file) will automatically download to your computer. Save this file securely, as it serves as the credential key for the migration endpoint.

Step 23: Configure Domain-Wide Delegation

In the Microsoft 365 prerequisites window, locate and click the blue Link next to the text "Click the link to add scopes for API access".

A new browser window will open, taking you to the Google Workspace Admin console. On the "Domain-wide Delegation" page, click the Add new button. You will then use the Client ID and API Scopes that were generated in the previous step to grant the necessary permissions.

Step 24: Authorize the API Connection

In the Add a new client ID pop-up window that appears in the Google Admin Console:

• Paste the Client ID (copied from the Microsoft 365 wizard) into the Client ID field.
• Paste the OAuth scopes (also from the wizard) into the OAuth scopes field.
• Click the Authorize button to save the configuration and grant the necessary permissions.

Manually Configure Google Workspace for Migration

If the automated tool is not an option, or if you prefer full control over the security settings, you can manually configure the necessary Google Cloud components.

Step 25: Create a Google Cloud Project

• Click on the project dropdown menu in the top navigation bar (often labeled Select a project).
• In the pop-up window, click New Project.
• Enter a project name (e.g., "M365-Migration-Project") and click Create.

Step 26: Configure and Create the Project

In the New Project screen that appears:

Enter a descriptive name in the Project name field (e.g., "M365-Migration-Project").
Under Location, browse and select your organization (if applicable) or leave it as "No organization".
Click the Create button to initialize the new project.

Step 27: Select the Created Project

Once the project is successfully created, a notification will appear in the top-right corner of the Google Cloud Console. Click on SELECT PROJECT within this notification to switch your active dashboard to the new project.

Step 28: Create a Service Account

1. Navigate to the IAM & Admin section in the Google Cloud Console (or visit https://console.cloud.google.com/iam-admin ).
2. From the left-hand menu, click on Service accounts.
3. At the top of the main pane, click the + CREATE SERVICE ACCOUNT button.

 

Step 29: Define Service Account Details

In the Create service account form:

1. Enter a descriptive name in the Service account name field (e.g., m365-migration-svc).
2. The Service account ID field will populate automatically based on your entry.
3. Click the CREATE AND CONTINUE button to save and proceed to the next step.

 

Step 30: Grant Access to the Service Account

1. In the "Grant this service account access to project" section, click the Select a role dropdown menu.
2. Choose Owner (under "Basic" or by searching for "Owner") to give the service account full access to the project.
3. Click CONTINUE to apply the role.
4. Finally, click DONE at the bottom of the page to complete the service account creation.

 

Step 31: Retrieve and Save the Client ID

After creating the service account, you will be redirected to the Service accounts list.

1. Locate your newly created service account in the table.
2. Find the OAuth 2 Client ID (a long string of numbers) in the corresponding column.
3. Copy this Client ID and save it in a secure location (like a Notepad file). You will need this ID later to configure domain-wide delegation in the Google Admin console.

 

Step 32: Generate the Private Key (JSON)

1. In the Service Accounts list, click on the email address (link) of the service account you just created.
2. On the service account details page, click the KEYS tab in the top navigation bar.
3. Click the ADD KEY dropdown button and select Create new key.
4. In the pop-up window, ensure JSON is selected as the "Key type".
5. Click CREATE. The JSON file containing your private key will automatically download to your computer.

 

Step 33: Select Key Type and Create

1. On the service account details page, switch to the KEYS tab.
2. Click the ADD KEY dropdown and select Create new key.
3. A pop-up window titled "Create private key" will appear. Select JSON as the Key type.
4. Click the CREATE button. The file will download immediately.

Step 34: Save the Downloaded Key

After clicking Create, a confirmation window will appear stating that the Private key saved to your computer. The JSON file will automatically download to your browser's default download location.

Crucial: This is the only time you can view or download this specific private key. If you lose it, you will need to generate a new one.

Step 35: Enable Required Google Workspace APIs

To allow the migration tool to access and move your data, you must manually enable three specific APIs in your project.

1. Navigate to the API Library:

• Go to APIs & Services > Library in the Google Cloud Console (or visit https://console.cloud.google.com/apis/library ).

2. Enable the following three APIs: Repeat the search and enable process for each of these services:

• Gmail API
• Google Calendar API
• Google People API
• Google Contacts API

Note: If an API is already enabled, the button will say "Manage" instead of "Enable". You can simply move to the next one.

Step 36: Add Domain-Wide Delegation

1. Open a new tab and log in to the Google Admin Console (admin.google.com).
2. Navigate to the Domain-wide Delegation page. You can use this direct link: https://admin.google.com/ac/owl/domainwidedelegation . (Alternatively, go to Security > Access and data control > API controls > Manage Domain Wide Delegation).
3. Click the Add new button to register your service account.

Step 37: Enter Client ID and Authorize Scopes

In the Add a new client ID popup window that appears:

1. Client ID: Paste the long numeric string you saved earlier (from Step 7).
2. OAuth scopes: Copy and paste the exact list of scopes below into this field: https://mail.google.com,https://www.googleapis.com/auth/contacts,https://www.googleapis.com/auth/calendar,https://www.googleapis.com/auth/gmail.settings.sharing,https://www.google.com/m8/feeds
3. Click the Authorize button.

 

You have now successfully completed all the required configurations in the Google Cloud Console and Google Workspace Admin Console (Service Account, APIs, and Domain-Wide Delegation).

• Leave the Google tabs open (just in case you need to copy values again).
• Switch your browser tab back to the Microsoft 365 Exchange Admin Center.
• You should still be on the Add migration batch wizard where you left off.

 

Step 38: Complete Prerequisites Check

Back in the Microsoft 365 Exchange Admin Center:

1. Verify that you are on the Prerequisites for Google Workspace migration page.
2. Since you have manually completed all the listed tasks (Service Account creation, API enablement, and Domain-wide delegation) in the previous steps, you can now proceed.
3. Click the Next button at the bottom of the screen.

Step 39: Create a New Migration Endpoint

1. The Set a migration endpoint window will now appear.
2. Select the option: Create a new migration endpoint.
3. Click Next.

Step 40: Configure Endpoint General Information

1. On the General information page, locate the Migration endpoint name field.
2. Type a unique name for this endpoint (e.g., GWorkspace_Endpoint).
3. Leave the Max concurrent migrations and Max concurrent incremental syncs fields at their default values (unless you have specific reasons to change them).
4. Click Next.

Step 41: Configure Google Workspace Connection

1. On the Google Workspace configuration page:

• Email address: Enter the email address of the Google Workspace Super Admin (this must be the account used to create the Service Account).
• JSON key: Click the button to upload (often labeled Choose File or Import) and select the .json file you downloaded to your computer earlier.

2. Once the file is uploaded and the email is entered, click Next.

Step 42: Confirm Endpoint Creation

1. You should now see a confirmation or the list of endpoints showing your new Migration Endpoint has been created successfully.
2. Click Next to proceed to the user selection stage.

Step 43: Create the User Migration CSV File

You need to create a simple CSV file that tells Microsoft 365 which users to migrate. Since we are using the Service Account (API) method, you do not need user passwords.

1. Open Excel or a plain text editor (like Notepad).
2. In the first row (A1), enter the exact header: Email Address (Note: Ensure there are no spaces in the header).
3. In the rows below, list the Microsoft 365 email addresses for every user you want to migrate in this batch.
4. Save the file as a .csv (Comma Separated Values) file (e.g., migration_users.csv).

Step 44: Import the User List (CSV)

1. On the Add user details page of the wizard, select the option to Manually upload a CSV file.
2. Click the Choose File (or "Browse") button.
3. Select the .csv file you just created (e.g., migration_users.csv).
4. Once the file is uploaded and validated, click Next to proceed.

Step 45: Configure Migration Settings

1. On the Move configuration window:

• Target delivery domain: Enter your Microsoft 365 routing domain (typically yourcompany.onmicrosoft.com). This ensures email routing works correctly during the migration.
  
• Select items to migrate: Check the boxes for the data types you want to move:
  

1. Mail
2. Calendar
3. Contacts (You can also select Rules if available/needed).

2. Click Next to proceed.

Step 46: Schedule and Start the Migration Batch

1. On the Schedule batch migration page, configure the final settings:

• Send a report to: By default, your admin email is selected. You can add other recipients who should receive the final status report.
  
• Start the migration batch: Select Automatically start the batch (or "Automatically processing the batch").
  
• End the migration batch: Select Automatically complete the migration batch.
  
• Time zone: Select your local time zone from the dropdown menu to ensure reports and schedules align with your time.

2. Click the Save button to finalize the wizard and begin the migration process.

Step 47: Finalize Batch Creation

1. Wait for Processing: The system will take a moment to process your request.
2. Confirmation: You will see a status message indicating Batch creation successful.
3. Action: Click the Done button to close the wizard.

Note: After clicking Done, you will be returned to the migration dashboard where you can monitor the progress of your new batch.

Step 48: Monitor Migration Progress

1. After clicking "Done," you will be redirected to the main Migration dashboard.
2. Locate your batch in the list. You will see the Status column change to Syncing.
3. Wait for Completion: The migration process will now copy data from Google Workspace to Microsoft 365. This can take significant time depending on the size of the mailboxes. You do not need to keep the window open; the process runs in the background.

Step 49: Verify Migration Completion

1. Wait for Data Transfer: As mentioned, this process will take time depending on the size of the mailboxes (ranging from minutes for test accounts to hours or days for large organizations).
2. Refresh Status: Periodically click the Refresh button (circular arrow icon) in the toolbar to update the list.
3. Confirm Completion: Once the data transfer is finished, the Status column will change from "Syncing" to Synced or Completed (depending on the batch finalization settings you chose).

We have successfully completed the full migration from Google Workspace to Microsoft 365. I hope this article has helped you understand how to perform a seamless Google Workspace migration using the automated batch method.

Important Post-Migration Reminder: Now that your data has been migrated, the final step is to update your MX Records in your DNS settings to point to Microsoft 365. This is critical to ensure that all new incoming emails are delivered directly to your new Microsoft 365 mailboxes instead of Google Workspace.

Update MX Records to Route Mail to Microsoft 365

While your old emails have been migrated, new emails may still be going to Google Workspace. To switch the flow of new emails to Microsoft 365, you must update your domain's MX (Mail Exchange) records.

To finalize the mail flow, you need to update your DNS records. Microsoft 365 provides a wizard to help you with this.

1. Open the Microsoft 365 Admin Center.
2. In the left-hand navigation pane, go to Settings > Domains.
3. Click on your specific domain name (e.g., yourcompany.com) to open its details.
4. Click on the Manage DNS (or Continue setup) button to view the required records.

Choose DNS Connection Method

• After clicking "Manage DNS," you will see the Connection options (or "How do you want to connect your domain?") page.
• Select the radio button for Add your own DNS records.

Note: This option allows you to manually copy the required MX, SPF, and CNAME records and paste them into your domain registrar (e.g., GoDaddy, Cloudflare, Namecheap). This is often safer than allowing Microsoft to access your DNS settings automatically.

• Click Continue.

Update DNS Records

• The wizard will now display a list of the specific records you need to add to your domain registrar (MX, CNAME, and TXT/SPF).
• Action: Log in to your domain registrar's website (e.g., GoDaddy, Namecheap) and create the new records exactly as shown on the screen.
  
• MX Record: Directs email to Microsoft 365.
• CNAME (Autodiscover): Helps Outlook and mobile apps find the server automatically.
• TXT (SPF): Authorizes Microsoft 365 to send email on your behalf.

• Once you have added all the values in your registrar, return to this window and click Continue.

Conclusion

Mission Accomplished!

By following this step-by-step procedure, you have successfully migrated your organization from Google Workspace to Microsoft 365. You’ve handled everything from setting up the Google Service Account to configuring the final DNS records.

Your users can now log in to their new Microsoft 365 accounts with all their historical emails, contacts, and calendars ready to go.