Migrating from Selenium 3 to Selenium 4 – Step-by-Step Guide 2026

If you're still running a Selenium 3-based framework in 2026, you've probably already hit some friction: browser vendors that no longer ship drivers the way they used to, cloud testing providers that assume W3C-compliant capabilities, or CI images that no longer play nicely with older dependency chains. At some point, migrating from Selenium 3 to Selenium 4 stops being optional and becomes the path of least resistance.

The good news is that this migration is rarely a full rewrite. Most Selenium 3 test logic — locators, waits, assertions, page objects — carries over unchanged. What actually needs attention is a fairly specific set of areas: how capabilities are constructed, how WebDriver instances are created, how Selenium Grid is configured, and a handful of APIs that were deprecated or removed along the way.

This guide walks through that migration step by step, based on what actually changes between the two versions rather than a generic feature tour of Selenium 4.

Advertisement

Selenium 3 vs Selenium 4: What Changed?

A few changes matter more than others when you're migrating an existing codebase.

W3C WebDriver Standardization

Selenium 3 supported both the legacy JSON Wire Protocol and the newer W3C WebDriver standard, with W3C compliance becoming the default around Selenium 3.11. Selenium 4 is built entirely around the W3C standard.

In practice, this mostly affects how capabilities are structured. Vendor-specific capabilities now need to be namespaced, such as being wrapped in a cloud:options style block for third-party cloud providers, rather than being passed as flat, unprefixed keys.

DesiredCapabilities

The DesiredCapabilities class itself still exists in Selenium 4, but its static factory methods such as DesiredCapabilities.chrome() and DesiredCapabilities.firefox() were removed.

Code relying on those static methods needs to move to browser-specific Options classes such as:

  • ChromeOptions
  • FirefoxOptions
  • EdgeOptions

Selenium Grid Architecture

Selenium Grid 4 replaced the Grid 3 Hub-and-Node architecture with a more modular architecture consisting of:

  • Router
  • Distributor
  • Session Map
  • New Session Queue
  • Event Bus
  • Node

Selenium Grid 4 still supports a Hub/Node-style deployment for teams that want it, alongside a fully distributed mode.

Relative Locators

Selenium 4 introduced relative, or "friendly," locators. These allow elements to be located relative to another element using methods such as:

  • above()
  • below()
  • toLeftOf()
  • toRightOf()
  • near()

This is an additive feature and does not require any migration by itself.

DevTools and Chrome DevTools Protocol Integration

Selenium 4 added built-in support for interacting with browser DevTools functionality, including capabilities such as:

  • Network interception
  • Console log capture
  • Geolocation overrides
  • Browser-level debugging and inspection

These capabilities were not available as first-class Selenium features in Selenium 3.

Selenium Manager

Starting with Selenium 4.6, Selenium ships with Selenium Manager, a built-in driver-management tool that can automatically resolve and configure browser drivers without requiring a separate driver-management dependency.

This is an optional improvement rather than a mandatory replacement for existing driver-management approaches.

Dependency Changes

The Maven group ID remains:

org.seleniumhq.selenium

Selenium 4 is modularized differently than Selenium 3, but using the selenium-java aggregate artifact remains the simplest approach for most projects.

Why Migrate from Selenium 3 to Selenium 4?

There are legitimate technical and organizational reasons to migrate, and it's useful to separate the two.

Technical Reasons

  • W3C WebDriver compliance improves compatibility with modern browsers and cloud testing vendors.
  • Selenium 4's Grid architecture is better suited to containerized and Kubernetes-based deployments.
  • Built-in DevTools access reduces the need for certain third-party browser-debugging integrations.
  • Selenium Manager can simplify driver management.
  • Selenium 3 no longer receives active feature development, while new browser and protocol capabilities are developed for Selenium 4.

None of this means Selenium 3 immediately stops working. Plenty of Selenium 3 code can still function with current browsers in certain environments.

The case for migration is primarily about reducing future compatibility risk and keeping the framework aligned with the modern Selenium ecosystem.

Organizational Reasons

  • Newer team members are more likely to be familiar with Selenium 4 patterns.
  • Current Selenium documentation and tutorials primarily target Selenium 4.
  • Cloud testing vendors increasingly document their integrations around Selenium 4 and W3C capabilities.
  • Long-term framework maintenance becomes easier when the project isn't dependent on an older major version.

Before You Start the Migration

A rushed migration can cost more time than it saves. Before changing dependencies, work through the following checklist:

  • Identify the exact Selenium version currently in use by checking pom.xml or build.gradle.
  • Confirm the Java version your project targets.
  • Check the Java compatibility requirements of the Selenium 4 version you plan to adopt.
  • Review Maven or Gradle configuration for transitive dependencies that may assume Selenium 3 APIs.
  • Confirm which browser versions your test environments actually use.
  • Identify all locations where WebDriver instances are created.
  • Search the codebase for DesiredCapabilities usage.
  • Search specifically for static factory calls such as DesiredCapabilities.chrome().
  • Review Selenium Grid configuration if Grid is being used.
  • Determine whether the existing Grid is Grid 3 Hub/Node or already partially migrated.
  • Review CI/CD pipeline definitions for hardcoded driver paths.
  • Check browser installation and driver-management logic.
  • Run the existing test suite and record a baseline.
  • Record existing failures and known flaky tests.
  • Create a dedicated migration branch or backup.

Establishing a clean baseline is one of the most important steps. Without a baseline, it becomes difficult to determine whether a failure after migration was caused by Selenium 4 or was already present.

Step 1: Create a Migration Branch

Keep the migration isolated from unrelated framework work.

git checkout -b selenium4-migration

Avoid merging unrelated feature branches or refactoring work into the migration branch.

If unrelated changes are included, it becomes much harder to identify whether a failure is caused by the Selenium upgrade.

Treat the migration branch as a dedicated, single-purpose branch until the upgrade has been verified.

Step 2: Update the Selenium Dependency

Maven

Update the selenium-java version in pom.xml:

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version><current-selenium-4-version></version>
</dependency>

Gradle

For Gradle:

implementation 'org.seleniumhq.selenium:selenium-java:<current-selenium-4-version>'

The version placeholder is intentional because Selenium 4 receives regular point releases.

Before locking a version, verify the current release and confirm that it is compatible with the Java version used by your project.

Step 3: Update WebDriver Initialization

Basic WebDriver instantiation did not change dramatically between Selenium 3 and Selenium 4. However, driver-management approaches have evolved.

Before: Selenium 3

System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
WebDriver driver = new ChromeDriver();

After: Selenium 4

WebDriver driver = new ChromeDriver();

Selenium Manager, available since Selenium 4.6, can automatically resolve the required browser driver.

If your project already uses WebDriverManager, you do not have to replace it. WebDriverManager continues to work with Selenium 4.

The important point is to confirm that your ChromeDriver, FirefoxDriver, or EdgeDriver construction still compiles and behaves correctly against the Selenium 4 dependency.

Step 4: Migrate DesiredCapabilities

This is often one of the biggest sources of compilation errors during the migration.

Selenium 3 code commonly used static factory methods from DesiredCapabilities.

Before: Selenium 3

DesiredCapabilities caps = DesiredCapabilities.chrome();
caps.setCapability("platform", "WINDOWS");

WebDriver driver =
        new RemoteWebDriver(new URL(gridUrl), caps);

After: Selenium 4

ChromeOptions options = new ChromeOptions();
options.setPlatformName("WINDOWS");

WebDriver driver =
        new RemoteWebDriver(new URL(gridUrl), options);

The DesiredCapabilities class itself has not been completely removed. However, the browser-specific static factory methods such as:

DesiredCapabilities.chrome();
DesiredCapabilities.firefox();
DesiredCapabilities.edge();
DesiredCapabilities.internetExplorer();
DesiredCapabilities.safari();

are no longer the recommended approach.

The modern replacement is to use browser-specific Options classes.

For example:

ChromeOptions options = new ChromeOptions();
FirefoxOptions options = new FirefoxOptions();
EdgeOptions options = new EdgeOptions();

These Options classes implement the capabilities interfaces needed by WebDriver.

Cloud Testing Capabilities

If your project integrates with a cloud testing provider, vendor-specific capabilities generally need to be placed inside the provider's namespaced options structure to comply with W3C capability requirements.

For example, instead of passing arbitrary flat capabilities, cloud platforms commonly use a structure similar to:

cloud:options

The exact namespace depends on the cloud provider.

Step 5: Review Deprecated APIs

Not every API marked as changed is necessarily removed.

Separate migration issues into these categories:

Deprecated but Still Present

The API still works but is marked for future removal.

These can usually be addressed later, but they should be tracked.

Changed Behavior

The method still exists, but its expected inputs or behavior have changed.

Capability handling is an important example.

Removed

The API no longer compiles.

The static DesiredCapabilities browser factory methods are a common example.

Still Fully Supported

Most core WebDriver APIs remain familiar, including:

  • findElement()
  • findElements()
  • click()
  • sendKeys()
  • Explicit waits
  • Implicit waits
  • WebDriverWait

Do not assume every compiler warning represents a breaking migration issue.

Review each warning and determine whether it is actually relevant to the Selenium 4 upgrade.

Step 6: Update Browser Options

Browser-specific Options classes are the standard way to configure browsers in Selenium 4.

Chrome

ChromeOptions options = new ChromeOptions();

options.addArguments("--start-maximized");
options.addArguments("--disable-notifications");

Firefox

FirefoxOptions firefoxOptions = new FirefoxOptions();

firefoxOptions.addPreference(
    "dom.webnotifications.enabled",
    false
);

Edge

EdgeOptions edgeOptions = new EdgeOptions();

edgeOptions.addArguments("--inprivate");

If Selenium 3 code previously passed browser-specific configuration through DesiredCapabilities, migrate those values to the corresponding Options class.

Step 7: Review Selenium Grid Configuration

Not every Selenium 3 Grid setup requires a complete redesign.

The appropriate migration path depends on the existing architecture.

Simple Hub/Node Setup

If you are running a traditional Hub/Node setup, Selenium Grid 4 still supports this deployment model.

The migration generally involves:

  • Updating the Selenium Grid version.
  • Reviewing configuration syntax.
  • Verifying node registration.
  • Verifying browser availability.
  • Validating session creation.

Standalone Mode

For smaller environments, Selenium Grid 4 Standalone mode can run the Grid components in a single process.

This can simplify configuration compared with older Grid deployments.

Distributed Grid

For larger environments, Selenium Grid 4 can run components independently:

  • Router
  • Distributor
  • Session Map
  • New Session Queue
  • Event Bus
  • Node

This architecture can be useful when scaling Grid infrastructure across containers or Kubernetes environments.

Docker-Based Grid

Official Selenium Docker images are commonly used for Selenium 4 environments.

Typical components include:

selenium/hub
selenium/node-chrome
selenium/standalone-chrome

When migrating, update the image versions and review the corresponding Docker Compose or Kubernetes configuration.

Step 8: Review RemoteWebDriver

RemoteWebDriver itself remains conceptually similar, but capability construction and Grid endpoint handling should be reviewed.

Before: Selenium 3

DesiredCapabilities caps = DesiredCapabilities.firefox();

WebDriver driver =
        new RemoteWebDriver(
            new URL("http://localhost:4444/wd/hub"),
            caps
        );

After: Selenium 4

FirefoxOptions options = new FirefoxOptions();

WebDriver driver =
        new RemoteWebDriver(
            new URL("http://localhost:4444"),
            options
        );

There are two important areas to verify:

  1. Replace the old DesiredCapabilities browser factory with the appropriate Options class.
  2. Confirm the Grid endpoint URL for the specific Grid 4 deployment mode.

Some Grid 4 deployments can accept requests without the traditional /wd/hub path.

Do not blindly change the URL without checking the actual Grid configuration.

Step 9: Review Test Framework Integration

Selenium migration and test-framework migration are separate concerns.

Unless there is an actual compatibility issue, avoid upgrading TestNG, JUnit, Maven plugins, or Gradle plugins at the same time.

TestNG and JUnit

Most:

remain unaffected by the Selenium version.

Maven and Gradle

The main changes are generally:

  • Selenium dependency version
  • Java compiler configuration
  • Transitive dependency resolution

If you upgrade multiple frameworks simultaneously, it becomes much harder to identify the source of a failure.

Step 10: Update CI/CD Pipelines

Whether you're using Jenkins, GitHub Actions, GitLab CI, or Azure DevOps, review the following areas.

Java Version

Confirm that the CI runner uses a Java version compatible with your selected Selenium release.

Dependency Resolution

Make sure the CI environment actually resolves the new Selenium dependency rather than using a stale cached version.

Browser Installation

Verify that the CI environment contains supported browser versions.

Driver Management

If using Selenium Manager:

  • Verify outbound network access.
  • Confirm the environment can download required drivers.

If using WebDriverManager or manually managed drivers:

  • Verify driver paths.
  • Verify driver versions.
  • Verify browser-driver compatibility.

Grid Connectivity

If tests run against Selenium Grid, verify:

  • Hostname
  • Port
  • Endpoint URL
  • Network accessibility
  • Authentication if applicable

Parallel Execution

Confirm that TestNG or JUnit parallel execution settings still work correctly.

Environment Variables

Review environment variables for:

  • Grid URLs
  • Browser configuration
  • Capability values
  • Credentials
  • Driver paths

Test Reports

Verify that reporting tools continue to process test results correctly.

Step 11: Run Tests in Stages

Do not immediately execute the entire regression suite.

Use staged validation.

Stage 1: Smoke Tests

Run a small group of tests that confirm:

  • The project compiles.
  • Browser sessions launch.
  • Basic navigation works.
  • Core WebDriver commands work.

Stage 2: Critical Regression Tests

Run the tests covering the application's most important workflows.

Stage 3: Full Regression

Run the complete test suite locally.

Stage 4: Cross-Browser Testing

Run the suite against every supported browser.

For example:

Chrome
Firefox
Edge
Safari

Use only the browsers actually supported by your project.

Stage 5: Parallel Execution

Validate parallel execution separately.

Shared state and driver-management problems can appear only during parallel execution.

Stage 6: CI Execution

Finally, run the complete suite in CI.

CI can expose:

  • Network problems
  • Driver-resolution problems
  • Browser installation problems
  • Resource contention
  • Grid connectivity problems

Step 12: Fix Common Migration Errors

Compilation Error: DesiredCapabilities.chrome()

Example:

DesiredCapabilities.chrome();

This browser-specific static factory method is no longer available.

Replace it with:

ChromeOptions options = new ChromeOptions();

NoSuchMethodError

A runtime NoSuchMethodError commonly indicates a dependency mismatch.

Check the dependency tree.

For Maven:

mvn dependency:tree

For Gradle:

gradle dependencies

Look for multiple Selenium versions being pulled into the project.

Session Creation Errors

Session creation failures against Selenium Grid may result from:

  • Invalid capabilities
  • Incorrect capability namespaces
  • Incorrect Grid endpoint
  • Browser availability problems
  • Node registration issues

Browser-Driver Compatibility Issues

If you manually manage browser drivers, verify that the driver is compatible with the installed browser.

This issue is separate from the Selenium client version but often becomes visible during migration.

Invalid Capabilities

Invalid capability errors can occur when unprefixed custom capability keys are passed under strict W3C validation.

Review vendor-specific capabilities and ensure they follow the provider's current W3C format.

RemoteWebDriver Connection Failures

Check:

  • Grid hostname
  • Grid port
  • /wd/hub usage
  • Standalone versus distributed Grid configuration
  • Network connectivity

Tests Pass but Behave Differently

Some tests may behave differently after migration because of timing assumptions or protocol-level changes.

If a test relies heavily on implicit timing, review it and replace fragile timing assumptions with appropriate explicit waits where necessary.

Selenium 3 vs Selenium 4 Code Examples

WebDriver Initialization

Selenium 3

System.setProperty(
    "webdriver.chrome.driver",
    "/path/to/chromedriver"
);

WebDriver driver = new ChromeDriver();

Selenium 4

WebDriver driver = new ChromeDriver();

Selenium Manager can automatically resolve the driver when no driver path is explicitly configured.

DesiredCapabilities

Selenium 3

DesiredCapabilities caps = DesiredCapabilities.chrome();

caps.setCapability(
    "platform",
    "WINDOWS"
);

Selenium 4

ChromeOptions options = new ChromeOptions();

options.setPlatformName("WINDOWS");

RemoteWebDriver

Selenium 3

WebDriver driver =
    new RemoteWebDriver(
        new URL("http://localhost:4444/wd/hub"),
        DesiredCapabilities.firefox()
    );

Selenium 4

WebDriver driver =
    new RemoteWebDriver(
        new URL("http://localhost:4444"),
        new FirefoxOptions()
    );

Selenium Grid

Older Grid 3 Assumption

A single Hub process routes WebDriver requests to registered Nodes.

Modern Grid 4 Approach

Grid 4 supports the traditional Hub/Node model as well as a modular distributed architecture containing components such as Router, Distributor, Session Map, New Session Queue, Event Bus, and Node.

The distributed architecture becomes particularly relevant when Grid infrastructure needs to scale across larger environments.

Selenium 4 Features Worth Adopting After Migration

Once the framework compiles and the baseline test suite passes, consider adopting Selenium 4 features separately from the migration.

Relative Locators

Relative Locators can help locate elements based on their position relative to another element.

Examples include:

above()
below()
toLeftOf()
toRightOf()
near()

Selenium Manager

Selenium Manager can simplify browser-driver management by automatically resolving the appropriate driver.

DevTools Integration

Selenium 4 provides access to browser DevTools functionality, including:

  • Network interception
  • Console logging
  • Geolocation
  • Browser-level inspection

Improved Grid Observability

Grid 4's architecture provides additional infrastructure-level visibility that can be useful for larger Grid deployments.

Modern Browser Options

The browser-specific Options classes provide a cleaner configuration model than the older generic DesiredCapabilities approach.

These features should be treated as follow-up improvements rather than migration requirements.

Selenium Manager vs WebDriverManager

Selenium Manager and WebDriverManager are two different driver-management approaches.

Selenium Manager

Selenium Manager is built into Selenium and has been available since Selenium 4.6.

It can automatically resolve and configure browser drivers when no driver path has been explicitly provided.

WebDriverManager

WebDriverManager is a separate third-party open-source library created by Boni Garcia.

It provides additional configuration capabilities, including options around:

  • Driver version selection
  • Proxy configuration
  • Browser management
  • Docker-based execution

Do You Need to Replace WebDriverManager?

No.

Migrating from Selenium 3 to Selenium 4 does not require replacing WebDriverManager.

An existing project can continue using WebDriverManager with Selenium 4.

Selenium Manager can be adopted later if the team wants to simplify driver management.

Selenium 3 to Selenium 4 Migration Checklist

Use the following checklist before considering the migration complete:

  • Selenium dependency updated to a current, verified Selenium 4 version
  • Java version compatibility checked
  • Browser versions confirmed
  • WebDriver initialization reviewed
  • DesiredCapabilities usage identified
  • Static DesiredCapabilities factory methods replaced
  • Chrome Options reviewed
  • Firefox Options reviewed
  • Edge Options reviewed
  • Deprecated APIs reviewed
  • RemoteWebDriver usage checked
  • Grid endpoint URLs verified
  • Selenium Grid configuration reviewed
  • CI/CD Java configuration updated
  • Dependency resolution verified
  • Browser and driver management verified
  • Smoke tests passing
  • Critical regression tests passing
  • Full regression suite passing
  • Cross-browser tests passing
  • Parallel execution validated
  • CI execution validated

Common Migration Mistakes

Updating the Dependency Without Reviewing the Codebase

Simply changing the Selenium version can result in a large number of compilation errors.

Identify affected APIs before starting the migration.

Changing Too Many Components at Once

Avoid upgrading Selenium, TestNG, JUnit, Maven plugins, browsers, reporting tools, and framework architecture simultaneously.

One change at a time makes troubleshooting much easier.

Ignoring Java Compatibility

An incompatible Java version can produce build failures that initially appear to be Selenium problems.

Verify Java compatibility before upgrading Selenium.

Assuming All Selenium 3 Code Requires Rewriting

Most Selenium 3 test logic does not require rewriting.

Locators, waits, assertions, Page Objects, and most WebDriver commands remain familiar.

Mixing Migration With Refactoring

Avoid redesigning the entire framework during the Selenium migration.

Complete the migration first and perform broader refactoring separately.

Ignoring Grid Configuration

Grid-related problems can affect the entire test execution environment.

Review Grid configuration early instead of waiting until the end.

Not Establishing a Baseline

Without a baseline, you cannot reliably determine whether failures are new or pre-existing.

Testing Only One Browser

Cross-browser issues can appear only with specific browser and driver combinations.

Ignoring CI/CD

A framework can pass locally while failing in CI because of:

  • Network restrictions
  • Browser versions
  • Driver resolution
  • Grid connectivity
  • Resource limitations

Treating Every Failure as a Selenium Problem

Some failures are caused by existing test instability or environment problems that only become visible during the migration test run.

Selenium 3 to Selenium 4 Migration Best Practices

Follow these practices for a controlled migration:

  • Upgrade incrementally.
  • Keep the migration isolated in its own branch.
  • Maintain a passing baseline.
  • Change one major area at a time.
  • Keep the Selenium version in one Maven property or Gradle version catalog.
  • Review deprecation warnings deliberately.
  • Validate every supported browser.
  • Test locally before CI.
  • Run critical regression tests before the full suite.
  • Document migration changes.
  • Avoid unrelated refactoring.
  • Keep driver creation centralized.
  • Validate Grid configuration separately.
  • Review capability formats for W3C compliance.

Selenium 3 to Selenium 4 Migration for Large Frameworks

Large frameworks introduce additional considerations.

Shared Driver Utilities

A centralized driver utility is often one of the most important areas to review.

If DesiredCapabilities and driver creation are already centralized, migration changes may only be required in one location.

Base Test Classes

Review setup and teardown methods for:

  • Driver initialization
  • Capability handling
  • Browser configuration
  • Grid configuration

Page Object Model

Most Page Object implementations should not require significant changes.

Page Objects generally interact with:

WebDriver
WebElement

rather than directly managing capabilities.

Driver Factory

A Driver Factory is an ideal location for Selenium-version-specific logic.

For example:

public class DriverFactory {

    public static WebDriver createDriver(String browser) {

        switch (browser.toLowerCase()) {

            case "chrome":
                return new ChromeDriver();

            case "firefox":
                return new FirefoxDriver();

            case "edge":
                return new EdgeDriver();

            default:
                throw new IllegalArgumentException(
                    "Unsupported browser: " + browser
                );
        }
    }
}

Centralizing WebDriver creation can significantly reduce the number of files affected by a migration.

Configuration Layers

Review configuration files that store browser capabilities or Grid values.

Flat capability structures may require changes to comply with W3C capability requirements.

Parallel Execution

Revalidate parallel execution after the migration.

Pay particular attention to:

  • Shared drivers
  • Static variables
  • Test data
  • ThreadLocal usage
  • Grid sessions

Grid Infrastructure

Large frameworks are more likely to use distributed Grid infrastructure.

Review:

  • Node configuration
  • Browser availability
  • Session routing
  • Grid endpoint
  • Scaling configuration
  • CI connectivity

CI/CD and Reporting

CI/CD pipelines, reporting systems, and test-data layers generally do not require Selenium-specific changes.

However, check for hidden assumptions around:

  • Driver paths
  • Grid URLs
  • Capability formats
  • Browser versions

Selenium 3 to Selenium 4 Migration for Interviews

What Are the Major Differences Between Selenium 3 and Selenium 4?

The major differences include:

  • Full W3C WebDriver standardization
  • Browser-specific Options classes replacing the old DesiredCapabilities factory methods
  • Redesigned Selenium Grid architecture
  • Relative Locators
  • DevTools integration
  • Selenium Manager from Selenium 4.6 onward

How Did Selenium 4 Adopt the W3C WebDriver Standard?

Selenium 3 supported the legacy JSON Wire Protocol and W3C WebDriver standard, with W3C becoming the default around Selenium 3.11.

Selenium 4 is built around the W3C WebDriver standard.

This means vendor-specific capabilities need to follow the appropriate namespaced structure.

How Would You Migrate a Large Selenium 3 Framework?

A practical migration approach would be:

  1. Establish a baseline.
  2. Create a dedicated migration branch.
  3. Update the Selenium dependency.
  4. Migrate DesiredCapabilities usage to Options classes.
  5. Review browser configuration.
  6. Review Grid configuration.
  7. Update CI/CD.
  8. Run smoke tests.
  9. Run critical regression tests.
  10. Run the full regression suite.
  11. Validate cross-browser execution.
  12. Validate parallel execution.
  13. Validate CI execution.

What Happened to DesiredCapabilities?

The DesiredCapabilities class itself still exists, but the old browser-specific static factory methods were removed.

Instead of:

DesiredCapabilities.chrome();

use:

ChromeOptions options = new ChromeOptions();

What Changes Were Introduced in Selenium Grid?

Grid 4 introduced a modular architecture containing components such as:

  • Router
  • Distributor
  • Session Map
  • New Session Queue
  • Event Bus
  • Node

Grid 4 also continues to support simpler deployment models.

What Is Selenium Manager?

Selenium Manager is Selenium's built-in driver-resolution tool.

It has been available since Selenium 4.6 and can automatically detect and configure the appropriate browser driver.

How Would You Troubleshoot Migration Failures?

Start by categorizing the failure:

  1. Compilation failure
  2. Runtime failure
  3. Dependency conflict
  4. Capability validation failure
  5. Grid connectivity failure
  6. Browser-driver compatibility failure
  7. CI environment failure

For dependency issues, inspect:

mvn dependency:tree

or:

gradle dependencies

For Grid failures, verify the endpoint, browser availability, node configuration, and capability format.

How Would You Validate That a Migrated Framework Is Stable?

Use staged validation:

  1. Smoke tests
  2. Critical regression
  3. Full regression
  4. Cross-browser testing
  5. Parallel execution
  6. CI execution

This approach makes failures easier to isolate.

Frequently Asked Questions

Can Selenium 3 Code Run With Selenium 4?

Not necessarily without changes.

Most core Selenium code can continue working, but code relying on removed APIs such as:

DesiredCapabilities.chrome()

requires migration.

Is Selenium 4 Backward Compatible With Selenium 3?

It is partially compatible.

Core WebDriver functionality carries over, but capability construction, certain APIs, and some Grid configuration patterns require review.

What Is the Biggest Change Between Selenium 3 and Selenium 4?

For many teams migrating an existing framework, the most visible code-level change is moving from the old browser-specific DesiredCapabilities factory methods to browser-specific Options classes.

The broader architectural changes include W3C WebDriver standardization and the redesigned Grid architecture.

How Do I Upgrade Selenium in Maven?

Update the selenium-java version in your pom.xml:

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-java</artifactId>
    <version><current-selenium-4-version></version>
</dependency>

Then rebuild the project and address any compilation or dependency issues.

Do I Need to Replace DesiredCapabilities?

You need to replace the old browser-specific static factory methods such as:

DesiredCapabilities.chrome();
DesiredCapabilities.firefox();

with Options classes such as:

ChromeOptions options = new ChromeOptions();
FirefoxOptions options = new FirefoxOptions();

The DesiredCapabilities class itself has not simply disappeared from Selenium.

What Happened to Selenium Grid in Selenium 4?

Selenium Grid was redesigned around a modular architecture that supports more flexible deployment and scaling.

Grid 4 also continues to support simpler deployment models for smaller environments.

Do I Need WebDriverManager With Selenium 4?

No.

Selenium 4.6 and later include Selenium Manager for automatic driver resolution.

However, existing projects using WebDriverManager can continue using it.

Does Selenium 4 Require a Specific Java Version?

Yes.

The minimum Java requirement depends on the specific Selenium 4 release you choose. Always verify the Java compatibility requirements of the exact version being adopted.

How Do I Troubleshoot Selenium 4 Migration Errors?

Start with compilation errors, especially capability-related errors.

Then check:

  • Selenium dependency conflicts
  • Java compatibility
  • Browser-driver compatibility
  • W3C capability formatting
  • Grid connectivity
  • CI configuration

Should I Migrate My Entire Framework at Once?

An incremental migration is generally easier to troubleshoot.

A practical sequence is:

Dependency
    ↓
Driver Initialization
    ↓
Capabilities / Options
    ↓
RemoteWebDriver
    ↓
Grid
    ↓
CI/CD
    ↓
Regression Validation

What Should I Test After Upgrading Selenium?

Use a staged approach:

  • Smoke tests
  • Critical regression tests
  • Full regression suite
  • Cross-browser tests
  • Parallel execution
  • CI execution

What Is Selenium Manager?

Selenium Manager is Selenium's built-in driver-resolution mechanism, available since Selenium 4.6.

It can automatically identify and configure browser drivers when an explicit driver path is not provided.

Is Selenium Grid Required to Migrate to Selenium 4?

No.

If your tests run locally and do not use Selenium Grid, there is no need to modify Grid configuration.

Will My Page Object Model Implementation Need Changes?

Generally, no.

Page Objects typically work with WebDriver and WebElement, so most Page Object implementations remain unchanged during the Selenium 3 to Selenium 4 migration.

The areas most likely to require changes are driver creation, capabilities, browser Options, RemoteWebDriver configuration, Grid configuration, and CI/CD setup.