What is jQuery Migrate, and Do You Need it?

jQuery Migrate is a compatibility library that helps older jQuery code continue working when a website uses a newer version of jQuery.

In WordPress, it exists for a practical reason: themes, plugins and custom scripts can remain in use for many years, while the version of jQuery bundled with WordPress changes over time.

The basic relationship is:

older jQuery code
↓
newer jQuery version
↓
removed or changed API
↓
jQuery Migrate restores compatibility
↓
old code can continue working

That makes jQuery Migrate useful.

It also creates an important question for site owners and developers:

Does my site genuinely need
jQuery Migrate?

or

Is it being loaded only because
WordPress includes it in the
standard jQuery dependency?

The answer is not the same for every WordPress site.

Some sites still contain themes, plugins or custom scripts that rely on legacy jQuery behavior. Others can run perfectly well without Migrate. And some sites no longer need jQuery at all on large parts of the frontend.

This guide explains what jQuery Migrate does, why WordPress includes it, how it differs from jQuery itself, what happens when you remove it, how to identify legacy dependencies and how to decide whether your WordPress site still needs it.

What is jQuery?

Before discussing Migrate, it helps to separate it from jQuery itself.

jQuery is a JavaScript library that provides APIs for tasks such as:

• DOM selection and manipulation;
• event handling;
• AJAX requests;
• animations;
• class and attribute manipulation;
• working with forms;
• cross-browser abstractions.

Historically, jQuery solved many browser inconsistencies and made common JavaScript operations considerably easier.

A typical jQuery example might look like:

jQuery(function($) {

    $('.menu-toggle').on(
        'click',
        function() {
            $('.menu').toggleClass(
                'is-open'
            );
        }
    );

});

WordPress has bundled jQuery for many years, and a large ecosystem of themes and plugins was built around it.

What is jQuery Migrate?

jQuery Migrate is a separate compatibility project maintained alongside jQuery.

Its purpose is to help developers move older jQuery code to newer versions of the library.

It does this primarily in two ways:

• restoring selected APIs or behaviors that newer jQuery versions removed;
• helping developers identify deprecated or removed APIs that old code still uses.

The jQuery project’s own documentation describes Migrate as a tool for identifying and fixing compatibility problems while upgrading older jQuery code.

jQuery and jQuery Migrate are not the same library

This distinction matters.

jQuery
=
main JavaScript library

jQuery Migrate
=
compatibility layer

A script can require jQuery without requiring legacy behavior.

For example:

wp_enqueue_script(
    'my-theme-navigation',
    get_theme_file_uri(
        '/assets/js/navigation.js'
    ),
    array( 'jquery' ),
    '1.0.0',
    array(
        'in_footer' => true,
    )
);

This tells WordPress that:

navigation.js
depends on
jquery

It does not prove that navigation.js needs jQuery Migrate.

For a deeper explanation of WordPress’s dependency system, see wp_enqueue_scripts explained.

Why does jQuery Migrate exist?

JavaScript libraries evolve.

Over time, APIs can be:

• deprecated;
• changed;
• removed;
• replaced with better alternatives.

Imagine an application written against an older jQuery version:

Application
↓
uses old jQuery API
↓
jQuery is upgraded
↓
API no longer behaves
as expected
↓
application breaks

Without a compatibility layer, developers may have to update every affected script before they can safely upgrade jQuery.

Migrate creates a transition path:

Application
↓
old API
↓
new jQuery
+
jQuery Migrate
↓
compatibility restored
↓
developer can identify
and modernize old code

jQuery Migrate is intended as a migration tool

This is perhaps the most important conceptual point.

The official jQuery Migrate documentation describes the project as a development tool that helps developers migrate away from APIs and features removed from jQuery Core.

The intended lifecycle is:

upgrade jQuery
↓
load Migrate
↓
identify compatibility issues
↓
fix deprecated code
↓
verify application
↓
eventually remove Migrate
where it is no longer required

It should not automatically become a permanent excuse to leave obsolete JavaScript untouched forever.

How jQuery Migrate restores compatibility

Suppose an older script uses functionality that modern jQuery removed.

Without Migrate:

legacy script
↓
calls removed API
↓
modern jQuery
↓
error or broken behavior

With an appropriate Migrate compatibility patch:

legacy script
↓
calls removed API
↓
jQuery Migrate intercepts
or restores behavior
↓
script can continue running

This gives developers time to update the original code instead of requiring every migration to happen simultaneously.

jQuery Migrate can also expose deprecated code

The development build of jQuery Migrate can generate browser-console messages when code uses deprecated or removed functionality.

These messages begin with:

JQMIGRATE:

The official jQuery Migrate warning documentation explains the warnings, their causes and recommended remediation.

This makes Migrate useful as a diagnostic tool rather than merely a compatibility shim.

Development and production builds behave differently

jQuery Migrate provides development and production builds.

The development version is designed for debugging and can expose compatibility warnings.

The minified production build does not normally print the same diagnostic warnings.

Therefore:

no JQMIGRATE warnings
in production console

does not necessarily mean:

no legacy jQuery code exists

The production build may simply be restoring compatibility quietly.

What version of jQuery does WordPress currently use?

Current WordPress Core registers:

jQuery 3.7.1

The current version can be verified directly in WordPress’s wp_default_scripts() implementation.

Do not assume versions from old WordPress optimization articles are still accurate.

What version of jQuery Migrate does WordPress currently use?

Current WordPress Core registers:

jQuery Migrate 3.4.1

Again, this is visible in the current WordPress script registry.

How WordPress currently registers jQuery

WordPress does something important in its default script registry.

Conceptually, Core registers:

jquery
↓
depends on
├── jquery-core
└── jquery-migrate

The current Core source defines the relationship approximately as:

jquery
→ jquery-core
→ jquery-migrate

More precisely, the jquery handle declares both jquery-core and jquery-migrate as dependencies.

Why does that matter?

If a theme or plugin enqueues:

jquery

WordPress’s dependency resolver sees:

jquery
↓
jquery-core
+
jquery-migrate

and the required registered components can be loaded.

This is why you may find jquery-migrate.min.js on a WordPress page even when your own code never explicitly requested it.

WordPress registering Migrate does not mean every page loads it

This distinction is essential.

registered
≠
enqueued
≠
downloaded

WordPress registers many scripts so they are available to themes, plugins and Core features.

A registered script does not automatically have to appear on every frontend request.

If nothing on a page requests the jquery dependency chain, the browser does not need to download that chain merely because Core knows about it.

Why does WordPress still include jQuery Migrate?

WordPress has an enormous backward-compatibility burden.

A WordPress installation may contain:

• a modern Core release;
• a theme created several years ago;
• a child theme with older custom JavaScript;
• plugins created across different eras;
• custom agency code;
• legacy jQuery plugins;
• old page-builder widgets.

Removing compatibility abruptly could break functionality across this ecosystem.

Migrate provides a bridge between modern jQuery and code written against older expectations.

WordPress’s jQuery modernization happened in stages

WordPress carried out a staged jQuery update process beginning around WordPress 5.5.

The WordPress Core team documented the transition in Updating jQuery version shipped with WordPress.

The broad objective was to modernize the jQuery version bundled with WordPress while giving themes and plugins time to address compatibility issues.

Why old articles about WordPress 5.5 can be misleading today

During the migration period, jQuery Migrate behavior changed as WordPress moved through the transition.

Many tutorials from that period therefore discuss:

WordPress 5.5
WordPress 5.6
WordPress 5.7
Enable jQuery Migrate Helper
temporary migration behavior

Those articles may be historically useful.

They are not necessarily descriptions of current WordPress Core.

When deciding what your current site loads, inspect the current Core source and your actual rendered pages.

Does your WordPress site need jQuery Migrate?

There is no universal yes-or-no answer.

Your site needs Migrate on a particular surface if required JavaScript depends on compatibility behavior that modern jQuery alone does not provide.

For example:

theme script
↓
uses removed jQuery behavior
↓
jQuery Migrate restores it
↓
feature works

Remove Migrate:

theme script
↓
removed behavior unavailable
↓
JavaScript error
↓
feature breaks

In that situation, the site still has a genuine compatibility dependency.

Your site may not need Migrate even if it uses jQuery

This is equally important.

A script might use:

jQuery
↓
supported jQuery 3.x APIs
↓
works without Migrate

Therefore:

site uses jQuery
≠
site needs jQuery Migrate

If you want to determine which scripts actually rely on older behavior, see Checking Your Site for Legacy jQuery Dependencies.

Your site may not need jQuery at all on some pages

There is another possibility:

page
↓
no jQuery-dependent scripts
↓
no reason for jQuery
↓
no reason for jQuery Migrate

This is different from removing Migrate while retaining jQuery.

Think of the decisions separately:

Question 1:
Does this page need jQuery?

Question 2:
If yes, does its code need
jQuery Migrate?

How can you tell whether Migrate is loading?

Open your website in browser DevTools.

Go to:

Network
↓
filter:
jquery

You may see URLs resembling:

/wp-includes/js/jquery/jquery.min.js

/wp-includes/js/jquery/jquery-migrate.min.js

If jquery-migrate appears, it is being delivered to that page.

Check more than the homepage

Dependencies can be conditional.

For example:

Homepage
→ no jQuery

Contact
→ jQuery

Product
→ jQuery

Checkout
→ jQuery + legacy integration

Inspect representative page types before drawing a site-wide conclusion.

Check whether WordPress considers Migrate enqueued

WordPress provides the wp_script_is() function for checking script state.

For example:

if (
    wp_script_is(
        'jquery-migrate',
        'enqueued'
    )
) {
    // jQuery Migrate is queued.
}

This can be useful during debugging.

Registered and enqueued are not the same thing

You can also test:

wp_script_is(
    'jquery-migrate',
    'registered'
);

But that answers a different question.

registered
=
WordPress knows about the script

enqueued
=
script has been requested

done
=
script has already been processed

Do not mistake registration for actual frontend usage.

How can you tell whether code actually needs Migrate?

The safest answer comes from a combination of:

• code inspection;
• jQuery Migrate diagnostics;
• dependency inspection;
• controlled removal testing;
• real interaction testing.

No single performance score can answer this reliably.

Use Migrate warnings during development

The development version of jQuery Migrate reports compatibility issues in the browser console.

Warnings begin with:

JQMIGRATE:

The project’s warning reference explains what individual warnings mean and how developers should address them.

What does a JQMIGRATE warning mean?

Broadly, it means some code encountered behavior that Migrate considers deprecated, removed or otherwise relevant to migration.

Conceptually:

plugin.js
↓
calls legacy API
↓
Migrate detects call
↓
console:
JQMIGRATE: ...

This gives you a starting point for identifying the component that should be modernized.

Not every warning means the page is currently broken

In fact, the reason you may only see a warning is that Migrate is keeping the old behavior working.

The sequence can be:

legacy call
↓
Migrate warning
↓
compatibility patch
↓
feature still works

That is exactly why warnings should not simply be ignored because the page looks normal.

Some warnings indicate future risk rather than current failure

The current jQuery Migrate documentation distinguishes between compatibility problems involving removed functionality and APIs that are merely deprecated.

That distinction matters.

An API may still work today but be something developers should migrate away from before a future jQuery upgrade.

jQuery 4 makes this increasingly relevant

The jQuery project has moved to jQuery 4.x, while current WordPress Core still registers jQuery 3.7.1.

The current jQuery Migrate documentation distinguishes compatibility generations:

jQuery 3.x
→ jQuery Migrate 3.x

jQuery 4.x
→ jQuery Migrate 4.x

It also recommends resolving 3.x compatibility issues before moving older applications to jQuery 4.x.

That makes eliminating unnecessary legacy assumptions valuable even before WordPress changes its bundled jQuery generation.

Do not manually replace WordPress jQuery with jQuery 4 just to modernize

This is not a safe shortcut.

A site can contain plugins and Core components expecting the version registered by WordPress.

Replacing:

WordPress jQuery 3.7.1

with:

latest jQuery 4.x

without auditing dependencies can create compatibility failures throughout the site.

Use the version supported and registered by your current WordPress environment unless you have a controlled development reason to do otherwise.

How to identify which component needs Migrate

When a warning appears, determine ownership.

The responsible code may belong to:

• the active theme;
• a child theme;
• a plugin;
• a page builder;
• custom JavaScript;
• a bundled third-party library;
• inline JavaScript.

The goal is to transform:

Migrate warning exists

into:

plugin X
↓
frontend.js
↓
legacy API Y
↓
needs update

Browser DevTools can help trace the source

Use the Console and Sources panels to inspect:

• the file generating the warning;
• the relevant line;
• stack traces;
• source maps;
• the plugin or theme path.

A URL such as:

/wp-content/plugins/example-plugin/
assets/js/frontend.js

immediately tells you much more than a generic compatibility warning.

Interact with the page while testing

Legacy code may not execute during initial page load.

Test:

• menus;
• dropdowns;
• modals;
• tabs;
• accordions;
• sliders;
• forms;
• AJAX filters;
• search;
• login;
• account features.

For ecommerce sites, test cart, checkout and account workflows separately.

Do not assume an old theme is the problem

Age is only a clue.

An older theme can be actively maintained and use supported APIs.

A recently created plugin can bundle an old jQuery library.

Use actual dependency evidence instead of guessing from release dates.

Common sources of Migrate dependencies

On mature WordPress installations, compatibility dependencies frequently come from:

• old sliders;
• legacy lightboxes;
• older navigation scripts;
• abandoned widgets;
• old form integrations;
• custom theme JavaScript;
• old jQuery plugins bundled inside newer software;
• historical agency snippets.

Check custom code carefully

Custom code is often easier to modernize because you control it.

If an old child-theme script causes the warning, you can:

1. identify the deprecated call;
2. replace it with a supported API;
3. test the feature;
4. confirm the warning disappears;
5. repeat until the compatibility requirement is gone.

Do not edit third-party plugin files directly

If the problem comes from:

/wp-content/plugins/vendor-plugin/

editing the plugin’s JavaScript directly is usually a poor long-term solution.

The next update may overwrite your changes.

Instead:

• update the plugin;
• check whether the vendor already fixed the problem;
• report the issue upstream;
• replace an abandoned plugin where practical.

Keeping plugins current also reduces other compatibility risks, as explained in The Risks of Not Updating WordPress Plugins.

Should you remove jQuery Migrate for performance?

Performance is one reason people consider removing it, but the benefit should not be exaggerated.

Removing an unnecessary JavaScript file can reduce:

• transferred bytes;
• JavaScript parsing;
• execution work;
• one frontend dependency.

That is useful when the dependency is genuinely unnecessary.

It is not usually a transformative performance optimization by itself.

Measure the actual cost

Use browser DevTools to inspect:

• compressed transfer size;
• cache behavior;
• execution time;
• pages where Migrate appears;
• whether jQuery itself is required.

For the wider process, see Reducing WordPress Front-End Page Weight.

Compatibility is more important than saving one small script

Imagine:

remove jquery-migrate
↓
save some JavaScript
↓
checkout breaks

That is not a performance optimization.

It is a regression.

Always evaluate the saved resource against the functionality it supports.

Migrate can have runtime consequences

jQuery Migrate does more than sit unused in the browser.

It can patch jQuery behavior to restore compatibility.

The project’s own warning documentation notes that using Migrate in production has performance implications and can complicate debugging because it modifies normal jQuery behavior.

This is another reason to remove genuine legacy dependencies over time rather than treating Migrate as permanent infrastructure by default.

Should you remove Migrate simply because PageSpeed mentions unused JavaScript?

No.

A performance report can identify that a script appears underused during a particular measurement.

It cannot automatically prove:

no site feature depends on
the compatibility behavior

That requires functional testing.

Test removal on staging

Never begin this experiment on a business-critical production site.

Use a staging environment following WordPress Staging Site Best Practices.

A sensible workflow is:

production
↓
create/update staging
↓
baseline functionality
↓
remove Migrate on frontend
↓
test
↓
inspect console
↓
fix dependencies
↓
repeat

How developers can temporarily remove Migrate for testing

Because the current WordPress jquery handle depends on both jquery-core and jquery-migrate, a developer can alter that dependency list during a controlled staging test.

For example:

add_action(
    'wp_default_scripts',
    function ( $scripts ) {

        if ( is_admin() ) {
            return;
        }

        if (
            ! isset(
                $scripts
                    ->registered[
                        'jquery'
                    ]
            )
        ) {
            return;
        }

        $jquery =
            $scripts
                ->registered[
                    'jquery'
                ];

        $jquery->deps =
            array_diff(
                $jquery->deps,
                array(
                    'jquery-migrate',
                )
            );
    }
);

This changes the frontend dependency graph from:

jquery
├── jquery-core
└── jquery-migrate

toward:

jquery
└── jquery-core

for the tested environment.

This snippet is a compatibility change, not a harmless cleanup

Do not paste it into production simply because the page still loads.

Its purpose is to answer:

What breaks when Migrate
is no longer available?

That question requires deliberate testing.

Why exclude wp-admin from the first test?

WordPress administration screens have their own dependency graph.

Current Core itself registers multiple administrative scripts that depend on jQuery.

Changing the global registry without understanding those relationships can affect:

• media management;
• plugin interfaces;
• administrative forms;
• editor-related workflows;
• Core UI behavior.

Start with the frontend when your goal is frontend optimization.

What should you test after removing Migrate?

Test every meaningful interactive feature.

At minimum:

• desktop navigation;
• mobile navigation;
• dropdowns;
• sticky headers;
• modals;
• tabs;
• accordions;
• carousels;
• galleries;
• forms;
• AJAX interactions;
• search;
• cookie or consent controls;
• login and registration;
• account pages.

WooCommerce requires extra care

On WooCommerce sites, also test:

• product variations;
• quantity controls;
• add-to-cart behavior;
• mini cart;
• cart updates;
• coupons;
• checkout fields;
• shipping updates;
• payment methods;
• order submission;
• My Account.

For a broader explanation of these surfaces, see WooCommerce Account and Checkout Pages, Explained.

Test logged-in and logged-out visitors

WordPress can enqueue different scripts depending on authentication state.

Test:

logged-out visitor
+
subscriber/customer
+
administrator where relevant

Do not assume one browser session represents every dependency path.

Test mobile independently

Some of the oldest JavaScript on WordPress sites exists specifically inside:

• mobile menus;
• touch sliders;
• responsive navigation;
• off-canvas interfaces.

A desktop site can appear perfect while its mobile navigation is completely broken.

Test forms after removal

Forms often contain JavaScript for:

• validation;
• conditional fields;
• AJAX submission;
• date pickers;
• file uploads;
• multi-step navigation.

Submit actual test forms instead of checking only whether they visually render.

Watch the Console for JavaScript exceptions

After removing Migrate, look for errors such as:

TypeError

ReferenceError

... is not a function

A visible feature may appear mostly functional while a secondary interaction fails.

What if the site breaks without Migrate?

Restore the compatibility layer first.

Then identify the responsible component.

The process should be:

remove Migrate on staging
↓
feature breaks
↓
restore Migrate
↓
identify responsible script
↓
update / replace / rewrite
↓
test again

Do not leave the site broken merely to maintain a cleaner Network panel.

What if everything works without Migrate?

That is encouraging, but continue testing before concluding the dependency is unnecessary.

Check:

• multiple page types;
• mobile;
• forms;
• authenticated states;
• ecommerce workflows;
• less frequently used widgets;
• browser console errors.

If all relevant workflows remain healthy, frontend Migrate removal may be reasonable.

Should you remove jQuery too?

That is a separate decision.

If you determine:

Migrate unnecessary

you have only established:

current jQuery code does not need
that compatibility layer

You have not established:

jQuery itself is unnecessary

Think of the dependency layers separately

Application script
↓
jQuery
↓
possibly jQuery Migrate

You can potentially remove:

Migrate

while retaining:

jQuery

because the application still uses supported jQuery APIs.

When can jQuery itself be removed?

Only when no required script on the relevant page depends directly or indirectly on it.

For that audit, continue with Checking Your Site for Legacy jQuery Dependencies.

Do not dequeue jQuery while dependent scripts remain

If a plugin declares:

array( 'jquery' )

that dependency exists for a reason unless proven otherwise.

Simply calling:

wp_dequeue_script(
    'jquery'
);

does not modernize the plugin.

It removes something the plugin says it needs.

Do not replace WordPress’s jQuery with a random CDN version

Another old optimization pattern is:

remove WordPress jQuery
↓
load latest CDN jQuery
↓
hope every plugin survives

This bypasses part of WordPress’s managed dependency environment and can introduce version mismatches.

If you are evaluating CDN versus local assets generally, see CDN vs. Self-Hosted Assets in WordPress.

Do not confuse jQuery Migrate with a security vulnerability

The mere presence of:

jquery-migrate.min.js

does not mean:

website compromised

or:

WordPress insecure

It is a compatibility library intentionally registered by WordPress Core.

As with any dependency, you should care about supported versions and actual vulnerabilities, but its existence alone is not evidence of a security problem.

Do not confuse technical debt with immediate vulnerability

If Migrate is compensating for an outdated plugin, that is useful maintenance information.

It may indicate:

• old frontend architecture;
• future compatibility risk;
• an abandoned component;
• code worth modernizing.

Those concerns should be investigated on their own merits rather than converted into vague claims that Migrate makes WordPress insecure.

Does removing jQuery Migrate improve SEO?

Not directly.

Search engines do not award rankings because a WordPress site stopped loading a compatibility library.

Removing genuinely unnecessary JavaScript can contribute to a cleaner frontend and potentially reduce resource work, but the SEO effect depends on actual performance and user-experience consequences.

Do not present Migrate removal as an SEO technique by itself.

Does removing jQuery Migrate improve Core Web Vitals?

Possibly by a small amount in some environments, but not automatically.

The result depends on:

• resource size;
• compression;
• cache state;
• execution cost;
• device performance;
• other JavaScript on the page.

A site with megabytes of unnecessary JavaScript will not become fast because one compatibility file disappeared.

The larger goal is dependency hygiene

The most useful reason to audit jQuery Migrate is architectural.

You want to know:

Which code needs compatibility?

Why?

Who owns that code?

Can it be updated?

Can it be replaced?

Can the dependency become conditional?

Can it eventually disappear?

This is much more valuable than blindly chasing one fewer request.

Use updates as an opportunity to reduce legacy dependencies

If a maintained plugin has replaced old jQuery APIs in a newer release, updating it may eliminate a Migrate dependency without any custom development.

Use a controlled update workflow rather than changing everything directly on production.

See Building a Staging-First WordPress Update Workflow.

Use redesigns as an opportunity to modernize old scripts

A redesign is an excellent time to review:

• legacy sliders;
• old navigation code;
• unused widgets;
• historical child-theme scripts;
• duplicate libraries;
• page-builder leftovers.

Instead of carrying every dependency into the new site, determine which functionality still exists and rebuild only what is actually required.

Modern JavaScript can replace many small jQuery tasks

For custom code, simple jQuery functionality can often be replaced with browser-native APIs.

For example:

jQuery('.button').on(
    'click',
    function() {
        jQuery('.panel')
            .toggleClass('open');
    }
);

can become:

const button =
    document.querySelector(
        '.button'
    );

const panel =
    document.querySelector(
        '.panel'
    );

if (button && panel) {
    button.addEventListener(
        'click',
        () => {
            panel.classList.toggle(
                'open'
            );
        }
    );
}

This can reduce jQuery dependencies when enough custom code is modernized.

But removing jQuery should not become an ideological project

If a maintained plugin:

• uses jQuery correctly;
• has no legacy compatibility warnings;
• performs well;
• is business-critical;

rewriting it simply because native JavaScript exists may provide little practical benefit.

The goal is maintainable software, not achieving a fashionable dependency count.

Conditional loading can be better than complete removal

Suppose only one page needs an older component:

Homepage
→ no jQuery

Blog
→ no jQuery

Contact
→ jQuery

Legacy configurator
→ jQuery + Migrate

A sensible architecture may be:

load dependencies
only on the configurator

rather than forcing a risky rewrite merely to eliminate Migrate from the entire installation.

Check optimization plugins before diagnosing Migrate problems

Performance plugins can modify JavaScript behavior through:

• combination;
• minification;
• delay;
• defer;
• execution reordering;
• asset removal.

If a site works normally until JavaScript optimization is enabled, the problem may involve execution order rather than Migrate itself.

Dependency declarations matter

A WordPress script should declare jQuery when it genuinely depends on it:

wp_enqueue_script(
    'example-script',
    $src,
    array( 'jquery' ),
    '1.0.0',
    array(
        'in_footer' => true,
    )
);

WordPress can then resolve the dependency order.

For a full explanation, see wp_enqueue_scripts explained.

Do not use script order as a substitute for dependencies

This is fragile:

jquery script tag
↓
plugin script tag
↓
custom script tag

with no declared relationship.

This is better:

jquery
↓
plugin-library
↓
custom-app

expressed through WordPress’s dependency system.

jQuery Migrate should be documented if you intentionally retain it

If testing confirms that a required component still needs Migrate, document the reason.

For example:

DEPENDENCY:
jquery-migrate

REQUIRED BY:
legacy booking widget

REASON:
uses deprecated jQuery API

STATUS:
replacement scheduled

SCOPE:
booking pages only

This converts an invisible legacy dependency into manageable technical debt.

Recheck after replacing the responsible component

Once the old component is updated or removed:

1. clear all caches;
2. reload staging;
3. inspect Network requests;
4. remove Migrate from the test dependency chain;
5. repeat functional testing;
6. inspect the console.

Do not assume the dependency disappeared simply because the plugin that originally introduced it changed.

Recheck after WordPress Core updates

WordPress’s bundled JavaScript versions and dependency graph can evolve.

Any guide that hardcodes:

WordPress always uses
jQuery version X

or

WordPress always handles
Migrate exactly this way

will eventually become outdated.

For version-sensitive maintenance, inspect the current wp_default_scripts() source.

What about jQuery Migrate 4?

jQuery Migrate 4 is designed for jQuery 4.x.

The current project documentation describes the compatibility relationship as:

jQuery 1.x
→ Migrate 1.x

jQuery 2.x
→ Migrate 1.x

jQuery 3.x
→ Migrate 3.x

jQuery 4.x
→ Migrate 4.x

Current WordPress Core’s registered pair remains:

jQuery 3.7.1
+
jQuery Migrate 3.4.1

Do not independently swap WordPress to Migrate 4 while Core is using jQuery 3.x.

What if a plugin bundles its own Migrate version?

Investigate carefully.

You can potentially end up with:

WordPress jQuery Migrate
+
plugin jQuery Migrate

or even different generations of the compatibility library.

The jQuery Migrate documentation warns against loading Migrate multiple times because it can create unpredictable behavior.

Check Network requests and generated HTML for duplicates.

A practical decision tree

Is jquery-migrate loaded?
│
├── No
│   └── Nothing to remove
│
└── Yes
    │
    ├── Does required code
    │   break without it?
    │
    │   ├── Yes
    │   │   ↓
    │   │   Identify owner
    │   │   ↓
    │   │   Update / replace /
    │   │   modernize
    │   │
    │   └── No
    │       ↓
    │       Test all critical
    │       workflows
    │       ↓
    │       Confirm console
    │       remains clean
    │       ↓
    │       Consider removing
    │       it from that surface

When you probably still need jQuery Migrate

• A required feature breaks when Migrate is removed.
• Your console identifies legacy APIs that Migrate is actively supporting.
• A required third-party component explicitly documents the dependency.
• You have not yet completed compatibility testing.
• You are in the middle of a staged jQuery modernization.

When you may no longer need it

• Your required scripts use supported jQuery APIs.
• No relevant Migrate compatibility warnings remain.
• The site works correctly without Migrate on staging.
• Critical workflows have been tested.
• Mobile behavior has been tested.
• Forms and ecommerce flows have been tested where applicable.
• No plugin or theme explicitly relies on legacy compatibility behavior.

When you may not need jQuery either

If the frontend contains no required jQuery-dependent code, you can investigate removing the larger dependency rather than focusing only on Migrate.

But perform that audit separately.

Start with Checking Your Site for Legacy jQuery Dependencies.

jQuery Migrate audit checklist

• Check whether jquery-migrate actually loads on the frontend.
• Do not confuse registered scripts with downloaded scripts.
• Check multiple page types.
• Check logged-in and logged-out states.
• Check desktop and mobile.
• Confirm the jQuery version bundled with the current WordPress release.
• Confirm the Migrate version bundled with the current WordPress release.
• Do not rely on old WordPress 5.5-era tutorials for current behavior.
• Understand that jquery currently depends on both jquery-core and jquery-migrate in Core.
• Use browser DevTools Network inspection.
• Use Console diagnostics during development.
• Look for JQMIGRATE: messages.
• Identify which file generates each warning.
• Identify whether the owner is Core, a theme, plugin or custom code.
• Use source maps where available.
• Interact with the page instead of testing only initial load.
• Test menus and navigation.
• Test modals, sliders and tabs.
• Test forms.
• Test AJAX functionality.
• Test WooCommerce separately where applicable.
• Check for duplicate jQuery copies.
• Check for duplicate Migrate copies.
• Do not replace WordPress jQuery with a random newer version.
• Do not dequeue jQuery while dependents remain.
• Update maintained plugins before creating custom workarounds.
• Do not directly edit third-party plugin files.
• Modernize custom legacy JavaScript when practical.
• Use native JavaScript where it provides a clear maintenance benefit.
• Do not rewrite healthy jQuery code merely for appearances.
• Test Migrate removal on staging first.
• Restore it immediately if critical functionality breaks.
• Document any dependency that intentionally remains.
• Consider conditional loading when only specific pages need legacy code.
• Measure actual performance gains.
• Do not describe Migrate removal as a direct SEO improvement.
• Recheck after major plugin and theme updates.
• Recheck after significant WordPress Core changes.

Related guides

• Checking Your Site for Legacy jQuery Dependencies
• wp_enqueue_scripts Explained
• Reducing WordPress Front-End Page Weight
• WordPress Staging Site Best Practices
• Building a Staging-First WordPress Update Workflow
• The Risks of Not Updating WordPress Plugins

Final recommendation

jQuery Migrate is neither something every WordPress site desperately needs nor something every site should immediately remove.

It is a compatibility layer.

Its job is to bridge:

older jQuery-dependent code
↓
newer jQuery behavior

Current WordPress Core still registers:

jquery 3.7.1
↓
jquery-core 3.7.1
+
jquery-migrate 3.4.1

That architecture exists because WordPress must support an ecosystem containing software written across many generations.

Your task is not to remove Migrate simply because you can see the file in DevTools.

Your task is to determine whether your site actually relies on what Migrate provides.

The safest process is:

inspect
↓
identify
↓
test on staging
↓
modernize legacy code
↓
test again
↓
remove only when unnecessary

If removing Migrate breaks an important feature, restore it and fix the underlying dependency first.

If extensive staging tests show that nothing requires its compatibility patches, removing it from the relevant frontend dependency chain can be a reasonable cleanup.

And if you discover that the site no longer needs jQuery itself on certain pages, that becomes a separate and potentially more valuable optimization project.

The goal is not to achieve a frontend with the fewest possible library names.

The goal is to know why each dependency exists, eliminate obsolete compatibility requirements and keep the site’s JavaScript predictable, maintainable and tested.