Battle of the Browsers: Migration Edition

Overview

The question of which browser to standardize on is a familiar one for IT teams. With options like Chrome, Edge, Firefox, and others, the decision goes beyond simple preference. Each browser brings its own balance of performance, compatibility, security, and manageability—making this as much a strategic choice as a technical one.

In recent years, many organizations have moved toward Microsoft Edge. Built on the Chromium engine (like Chrome), Edge delivers comparable performance and compatibility while adding enterprise-focused advantages. These include native Microsoft 365 integration, enhanced security features such as SmartScreen and Application Guard, and robust centralized management through Group Policy and Intune.

The Challenge

If the benefits are clear, why isn’t everyone switching?

The reality is that most environments carry years of legacy decisions. Organizations have historically standardized on browsers like Internet Explorer (now retired), Chrome, or Firefox. Over time, internal applications, plugins, and workflows were developed specifically for those platforms.

As a result, changing browsers isn’t just a technical swap—it can impact:

• Legacy applications
• Authentication workflows
• Compliance requirements
• End-user habits

Testing, validation, and user retraining quickly become necessary parts of the process.

The Goal

My primary objective went beyond simply migrating browsers. I wanted to minimize disruption to the end user by:

• Migrating Chrome user data seamlessly
• Handling Chrome uninstallation (optional)
• Automating the entire process at scale

Most available solutions relied heavily on manual steps. While effective in small environments, they don’t scale well. And as we’ve all seen, user adoption follows a predictable pattern: early adopters jump in, the majority follow with guidance, and a final group waits until change is unavoidable.

The question became: Can we fully automate this process while preserving the user experience?

Tools and Utilities Used

• PSAppDeployToolkit (v4.1.5 or newer) 
• Group Policy Management 
• SCCM (System Center Configuration Manager) 

The HowStart by downloading PSAppDeployToolkit. A key function used here is:

• Start-ADTProcessAsUser - This allows processes to run in the context of the logged-in user—critical because SCCM deployments typically execute under the SYSTEM account.

If you’re only migrating user data, no additional tools are required. However, if Chrome removal is part of your plan, you can incorporate a custom PowerShell function (for example, from GitHub). While PSAppDeployToolkit includes built-in uninstall options, a custom approach can offer greater flexibility.

Because this process runs per user, validation is important.

To track successful execution, I implemented a custom registry “tattoo” as a marker indicating:

• Data migration completed
• (Optional) Chrome removal succeeded

This ensures accurate detection and reporting across shared or multi-user devices

Next, configure Microsoft Edge to support the migration. You can either:

• Embed these settings directly in your script, or
• Apply them via Group Policy

For my use case, I targeted specific data types. Microsoft provides guidance for importing favorites and other data.

Additionally, when importing from Chrome, one critical policy must be configured:

• AutoImportAtFirstRun

This setting defines the data source Edge uses during its first run. It’s essential that this step executes in the context of the logged-in user, not SYSTEM.

In the post-install phase, you can choose whether to:

• Keep Chrome installed, or
• Remove it as part of the transition

This decision will depend on your organization’s rollout strategy and fallback requirements.

After execution, the registry tattoo is updated to confirm:

• Successful script execution
• Chrome removal status (if applicable)

This provides a reliable detection method for SCCM.

The SCCM deployment follows standard application packaging steps, with a few key considerations:

Installation Command

• Invoke-AppDeployToolkit.exe -DeployMode Interactive

Detection should be based on the current logged-in user, not just the device. This is especially important for:

• Shared devices
• Multi-user environments

Each user must have their data migrated individually.

Lastly, Configure SCCM with the following in mind:

• Install behavior: SYSTEM
• Run only when a user is logged in
• Allow user interaction

Running as SYSTEM ensures proper permissions, while user interaction ensures that user-context processes (like data migration) execute successfully.

And there you have it. Once everything is configured, deploy the application to your systems, ensure it runs under the SYSTEM context, and allow users to interact with the installation. This interaction is key to ensuring the user-context portions of the migration—especially data import—execute successfully.

With the right deployment settings in place, the process becomes largely hands-off for IT while still delivering a seamless experience for end users.

Final Thoughts

Migrating browsers at scale isn’t just about technology—it’s about user experience. By automating data migration, validating success, and carefully balancing SYSTEM and user context execution, you can significantly reduce friction during the transition.

The result is a smoother rollout, fewer support tickets, and a more seamless experience for end users—exactly what a successful modernization effort should deliver.