Jetpack is the Swiss Army knife of WordPress plugins, and that is precisely the problem. It bundles roughly forty features behind a single plugin and a mandatory WordPress.com connection, so even if you only ever wanted its contact form, you are loading a sprawling codebase, phoning home to Automattic's servers, and accepting whatever the next auto-update decides to enable. The fix is not to suffer it, and it is not to rip everything out blindly either. It is to figure out which Jetpack modules you genuinely rely on, then replace each one with a focused, single-purpose plugin that does that job better.

First, find out what Jetpack is actually doing for you

Before you deactivate anything, open Jetpack → Settings and walk through the toggles, then visit yoursite.com/wp-admin/admin.php?page=jetpack#/settings module by module. Most people are stunned by how little they use. The features that people genuinely depend on tend to be a short list: the contact form, image CDN (Site Accelerator/Photon), lazy loading, related posts, social auto-sharing (Publicize), downtime monitoring, brute-force protection, and stats. Everything else, sharing buttons, tiled galleries, Markdown, custom CSS, infinite scroll, is either rarely used or already native to modern WordPress and your theme.

Write the list down. The migration is simply working through it, one module at a time, and the order matters less than the discipline of replacing before you remove.

Replace the modules you actually use

Contact forms

Jetpack's form is the single most common reason people keep the plugin, and it is also the easiest to replace. The catch nobody mentions: your existing form submissions and the form markup itself live inside Jetpack, so deactivating it breaks live forms and orphans your Feedback entries. Export Feedback to CSV first. Then rebuild with Fluent Forms (lean, fast, generous free tier) or the ubiquitous WPForms. Recreate the form, point your DNS-verified sending through an SMTP plugin like FluentSMTP or Post SMTP so submissions actually arrive, and only then swap the shortcode on your live page.

Image CDN and lazy loading

Jetpack's Site Accelerator rewrites your image URLs to serve them from Automattic's CDN for free, which is genuinely useful, and the thing people most fear losing. But it offers no control: no WebP/AVIF conversion guarantees, no purging, no analytics. Replace it with a real image plugin plus a real CDN. EWWW, ShortPixel, or Imagify will compress and convert your library to WebP/AVIF, often cutting image weight 30 to 60 percent. For delivery, Cloudflare's free plan caches and serves those images globally. As for lazy loading, you can drop Jetpack's entirely: WordPress core has shipped native loading="lazy" on images since 5.5, so this module is pure redundancy today.

Jetpack computes related posts on WordPress.com's servers, which is why it works without taxing your host but also why you cannot tune it. Contextual Related Posts or Yet Another Related Posts Plugin (YARPP) do the matching locally with full control over the algorithm, thumbnails, and templates. On a large site, cache the queries (both plugins support it) so the relevance lookup does not add database load on every page view.

Social auto-sharing (Publicize)

Publicize is being spun out by Automattic into its own Jetpack Social plugin, which is itself a sign of the direction of travel: even Automattic is unbundling. If you want to leave the ecosystem entirely, Blog2Social or a Make/Zapier webhook on post-publish gives you the same cross-posting without any WordPress.com tie.

Stats

Jetpack Stats are simple and now sometimes paid for commercial sites. If you only want pageview counts, keep them or switch to the privacy-first, cookieless Independent Analytics or a hosted Plausible/Fathom account. If you need funnels and events, you were always going to outgrow Jetpack Stats anyway, so move to GA4 or PostHog and be done.

Security: downtime monitoring and brute-force protection

This is the module to handle most carefully, because removing it without a replacement leaves a real gap. Jetpack's brute-force protection and login throttling should be replaced before you deactivate, not after. Wordfence or Solid Security (formerly iThemes) cover login limiting, two-factor, and malware scanning far more thoroughly. For uptime monitoring, a free external service like UptimeRobot or BetterStack checks your site from outside your own infrastructure, which is more trustworthy than a plugin that goes down with the site it is meant to watch.

The disconnect, step by step

Once every module on your list has a working replacement live on the site, the actual removal is anticlimactic:

Take a full backup with UpdraftPlus or your host's snapshot. Jetpack stores subscriber data and form feedback, so this is your safety net.
Export anything Jetpack owns: Feedback (form submissions) to CSV, and your email subscribers via Jetpack → Settings → Discussion if you used the Subscriptions module, because those subscribers are stored on WordPress.com and vanish when you disconnect. Move them to a real email tool like MailPoet or Kit first.
Deactivate Jetpack and click through your key templates: home, a post with related posts, a page with a form, an image-heavy gallery. Confirm nothing is visibly broken.
Delete the plugin. Then disconnect the site under your WordPress.com account at wordpress.com/me/security/connected-applications so the link is fully severed.
Clean up. Jetpack leaves jetpack_* rows in wp_options. They are harmless but tidy them with a database cleanup plugin if you care about a clean install.

What you gain, and the one trade-off to accept

The payoff is concrete. You shed a heavy plugin and the WordPress.com connection it requires, you stop sending traffic data to Automattic, and you replace opaque managed features with tools you can configure, cache, and audit. On a typical site, dropping Jetpack alongside switching to a proper image pipeline and Cloudflare is exactly the kind of change that moves Largest Contentful Paint under the 2.5-second threshold Google wants, because you have removed render-blocking scripts and gained real control over image delivery.

The honest trade-off: convenience. Jetpack's appeal was always that one connection handled a dozen jobs with zero configuration. Replacing it means running five or six plugins instead of one and learning each. For most sites that is a net win, fewer total kilobytes, faster pages, no vendor lock-in, but if you run dozens of tiny client sites and value a single managed dashboard above all else, Jetpack's bundle may still earn its place. Decide deliberately. The point of this exercise is not to be plugin-minimalist for its own sake; it is to own your stack instead of renting forty features to use four.

Migrating from Jetpack to Specialized Plugins