Restoring WordPress websites—especially multisite networks—can be a complex and high-stakes process. When a plugin like Duplicator fails to properly reinstate essential components such as subsite plugins, the results can range from partial downtime to critical feature loss. In large, multi-user environments, this issue can disrupt organizational workflows, damage SEO rankings, or even lead to service-level agreement (SLA) violations. This article explores a real-world scenario in which the popular migration plugin Duplicator failed to restore subsite plugins in a multisite network, and how a strategic plugin mapping workflow ensured recovery and full functionality.

TL;DR

Duplicator encountered issues restoring individual subsite plugins during multisite migrations, leading to missing functionalities and broken dependencies. This was due to the way multisite data structures store site-specific plugin use. A targeted plugin mapping workflow was developed to correlate plugin activation records with their correct subsites. This approach ensured that each subsite regained full functionality, maintaining network integrity and user experience.

The Problem: Duplicator’s Multisite Limitations

WordPress Duplicator is a widely-used tool for cloning and migrating websites. However, when handling multisite environments, challenges surface due to how plugins and other assets are shared yet selectively activated across sites.

Multisite networks require a precise understanding of where plugins are activated:

• Network Activated Plugins: These are active across all subsites.
• Subsite Activated Plugins: These are individually enabled or disabled within each subsite’s admin dashboard.

During a recent migration of a large educational platform, Duplicator successfully moved core files and the primary database. But after restoration, several subsites appeared incomplete or even non-functional. Upon investigation, it became clear that while network-activated plugins were restored, subsite-specific plugins had not been re-enabled correctly.

Diagnosing the Failure

The failure was rooted in a disconnect between Duplicator’s export mechanism and the database architecture of multisite networks. Each subsite within a multisite environment has its own set of related rows in various database tables such as:

• wp_x_options — where x refers to the subsite ID
• wp_sitemeta
• wp_blogs

Through these tables, WordPress determines which plugins are active for which subsites. If a plugin is not ‘network-activated’, it must be enabled for individual subsites. Duplicator, unfortunately, did not correctly parse and remap these plugin activation details during restoration.

Consequences of Incomplete Plugin Restoration

The aftermath caused multiple issues across various subsites:

• Contact forms disappeared where Contact Form 7 wasn’t re-enabled
• Subsite-specific SEO tools were deactivated, affecting rankings
• eCommerce features tied to WooCommerce were lost in vendor subsites
• Custom post types stopped rendering without their associated plugins

The situation demanded a highly coordinated approach to prevent prolonged site outages. Standard plugin reinstallation wasn’t feasible due to the scale and need for accuracy.

Understanding Subsite Plugin Architecture

Before implementing a fix, a deeper understanding of how WordPress handles plugin states in multisite environments was essential. In non-multisite installs, plugin states are stored globally. However, in multisite mode:

• Network-wide plugins: Stored in the wp_sitemeta table under the key active_sitewide_plugins.
• Subsite-specific plugins: Stored in each subsite’s wp_x_options table under the key active_plugins.

This separation means that during migration, any tool must map plugin states correctly to subsite IDs—a feature Duplicator missed in this particular case, leading to broken dependencies.

The Plugin Mapping Workflow

A temporary reinstatement team was assembled to recover full functionality without risking data corruption. The following steps composed the plugin mapping restoration workflow:

1. Identify Subsite IDs and Plugin Usage

Using a combination of SQL queries and WP-CLI tools, the team documented which plugins were originally active in each subsite. The following command helped extract this data:

wp site list --fields=blog_id,url
wp option get active_plugins --url=subsite.example.com

2. Cross-reference With Plugin Folder

This step ensured no mismatch between plugin handles in the database and actual folders in the wp-content/plugins directory. Mismatches could cause admin-level fatal errors or white screens.

3. Re-map Plugin Activations

For each subsite, the following action re-activated the required plugins:

wp plugin activate plugin-slug --url=subsite.example.com

These commands were scripted and executed via Bash scripts with error-handling flags to prevent the entire script from halting due to one failed activation.

4. Validate Plugin Dependencies and Hooks

Post activation, manual validation was performed through the admin dashboards, ensuring that all user functionalities, shortcodes, and post types rendered correctly.

5. Documentation for Future Migrations

A documentation file was compiled listing:

• Each subsite
• Its domain/path
• Its plugin suite

This resource now serves as a baseline for cross-verification in future migrations, even if performed using different tools such as WP Migrate DB Pro or manual SQL imports.

Plugins That Can Help in the Future

To prepare for future scenarios and avoid similar Duplicator shortcomings, some additional plugins and tools were identified as helpful in both export and import phases:

• WP Migrate DB Pro with Multisite Tools Addon: Offers more control over serialized data and site-specific entries.
• NS Cloner: Useful for duplicating subsites internally without breaking plugin mappings.
• WP CLI Commands: Though technically not a plugin, these are invaluable for multisite automation.

Post-Mortem Lessons Learned

This event revealed an important truth: Even widely trusted plugins like Duplicator require thorough testing in advanced use cases like multisites. Some key takeaways include:

• Testing in a staging environment is non-negotiable.
• Plugin activation status must be handled at both network and subsite level.
• Backup is not just data—it includes the state and configuration logic.

By integrating a mapping workflow, the team not only salvaged what could have been a major platform failure but also built a framework for resilience in future migrations.

Conclusion

Restoring a WordPress multisite network is not simply about copying files and ensuring the database transfer completes. It requires an intimate understanding of how individual components—especially plugins—fit into the broader architecture. Duplicator offers excellent utility for single-site migrations but has critical limitations in multisite cases, particularly regarding subsite plugin restoration.

Through a careful plugin mapping workflow, the migrating team overcame these limitations and ensured complete subsite recovery. This experience underscores the importance of precision, documentation, and proactive validation in complex WordPress environments, and provides a roadmap for others facing similar challenges.