Cordova Plugins in a Capacitor Upgrade: What to Check

Inventory the feature behind each package

Record plugin package/version, JavaScript wrapper, native libraries, platform support and the application feature that calls it. Include plugins configured in legacy assets but missing from current imports, private forks and native calls.

The official Cordova plugin guidance supports installing compatible plugins through the package manager and syncing them. It also documents unsupported install variables, auto-configuration and hooks, plus known incompatible plugins. That compatibility layer is not a promise about every plugin release.

npx cap ls
rg 'cordova|@ionic-native/|@awesome-cordova-plugins/' src package.json
rg 'preference|hook|framework|config-file|edit-config' config.xml

Run in your trusted application with its local CLI. Adjust source paths and inspect the installed plugin's plugin.xml separately. Text search identifies candidates, not whether a feature is safely removable.

Make a decision with a stated condition

Retain

The feature is needed and the exact plugin release has acceptable evidence for the chosen runtime/platform. Document manual configuration and the tests still needed. Retaining now does not remove future maintenance work.

Replace

A supported alternative covers the required feature, or a proven blocker makes retention impractical. Compare API shape, callbacks, permissions, background behavior and persistent data before selecting the replacement.

Remove

The feature is unused or provided elsewhere, and you verified application/native references and data consequences. Remove the implementation and unused wrapper together only after that review.

Manually investigate or test

Support evidence is absent, the plugin has custom code, or device behavior is central. Record an owner and test/decision needed. Lack of evidence alone is not a finding that replacement is mandatory.

Keep the evidence label separate from the action. A plugin can be Android build-verified while still needing iOS review. Use the compatibility classification for that distinction.

Check replacement coverage, not only a similar name

Compare the actual methods and options used by the app with the candidate implementation. Check platform-specific behavior, cancellation/error handling, file formats, stored paths and any server-side expectations.

Use the official migration review as the starting point: alternatives can differ in functionality, and incompatible plugins can be skipped. A wrapper upgrade alone does not replace native code.

Before changing a data-owning plugin, build an upgrade-installation test. Seed representative records in the existing version, install the migrated build and verify read/write/recovery behavior. A clean install cannot reveal lost databases or changed storage locations.

Translate required native configuration explicitly

Inspect plugin.xml and the plugin's installation instructions for framework dependencies, manifest contributions, iOS usage descriptions and entitlements. Map settings into the native projects rather than assuming old Cordova hooks will run during sync.

The Cordova migration guide discusses manual permissions and configuration. Audit your real plugin requirements; adding every historical permission can broaden access without helping the current feature.

• Android: compare Maven/native library versions, manifest components, minimum SDK, Java/Kotlin targets and permission request behavior with the selected toolchain.
• iOS: check podspec/Swift package constraints, deployment targets, usage descriptions, entitlements and app-target membership.
• Both: record what sync generates versus what your team maintains, so another sync or build does not silently erase an essential change.

Review dependency-manager and origin changes

Do not combine plugin replacement and CocoaPods → SPM conversion without checking plugin support. Ionic's SPM guidance notes that third-party plugins need suitable support and Cordova support may require work. For an existing CocoaPods app, retaining that setup can make the runtime migration easier to isolate.

A Cordova → Capacitor change can also alter the web origin. The official scheme guidance highlights origin-bound storage. Inspect existing scheme/hostname configuration and test installed-user data before selecting a configuration change. Do not copy a scheme override without understanding your current origin.

Assess abandoned plugins without guessing compatibility

Inspect archived status, release history, unresolved native upgrade issues and maintainer response. An old release is a maintenance signal, not proof of failure. A recently updated README is not proof that SDK changes were tested.

If keeping a fork, identify who owns native fixes and how they will be tested. If replacing it, budget call-site changes and data migration. If the feature is optional, document the behavior when unavailable instead of hiding a failed native call.

Verify what sync actually retained

1. Make one plugin decision/change at a time on a migration branch.
2. Build web assets, sync installed native platforms and read warnings about skipped plugins.
3. Inspect native dependency/configuration changes and build both platforms.
4. Test the feature on real devices with granted/denied permissions, cancellation and background/resume.
5. Test an upgrade installation and stored data wherever the feature owns persistent state.

Keep old native assets and rollback evidence until the new integration has been verified. The wider readiness checklist helps separate package cleanup from release readiness; the Capacitor migration sequence keeps major-version work attributable.