Magento Open Source extension audit guide

Magento Open Source extension audit before an upgrade or migration

An extension audit inventories every third-party module, theme and language package on your store, then assigns each one a decision: keep, replace or remove. Run it before the platform moves, not after an upgrade fails in staging. The typical situation is a self-hosted Magento Open Source store built over several years, with extensions added for shipping, promotions, tax, payments and marketing, and a patch or upgrade now due. The 2.4.x line you run has a published end of support date, so the question is no longer whether to move but which extensions will still work when you do. Treat the audit as the first deliverable of the upgrade plan, because its output sets the scope, the test effort and the vendor conversations that follow.

Extensions drive upgrade effort more than core code does. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as the main drivers of effort, and it references the Upgrade Compatibility Tool for checking code against target versions. Each extension is a separate codebase with its own release cadence, its own dependencies and its own assumptions about the PHP and service versions underneath. Adobe also recommends upgrading every patch cycle to stay secure and PCI compliant, which makes the audit a recurring task rather than a one-time project. Ask each extension vendor in writing which 2.4.x and PHP versions the current release supports, and record the date of its last release. A vendor that cannot answer either question is a replacement candidate.

The target version changes what each extension must support. Magento Open Source 2.4.9, released in May 2026, cites official support for PHP 8.5 and Symfony 7.4 LTS, and its system requirements pair PHP 8.5 with MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30. Adobe supports only the listed combinations. If you target 2.4.8-p5 instead, its listed PHP versions are 8.4 and 8.3, so an extension that requires PHP 8.5 blocks that path. Compare each extension's Composer constraints against the exact PHP and framework versions in your target, and flag any extension that depends on a service client library outside the supported matrix. From 2.4.7, Content Security Policy runs in restrict mode by default on payment pages, so extensions that inject inline scripts into checkout need review as well.

A vendor list check tells you which extensions are installed and which version each one is. It does not show what they change. Three patterns make an audit harder. First, core overrides: an extension or a local customization may copy or rewrite a core class, template or layout file, and that copy will not appear in any extension list. Search the codebase for overrides and compare each one with the upstream file for your current version. Second, abandoned packages: a package with no recent release may still install cleanly today yet fail on the next PHP version. Third, extensions that touch checkout or payment pages: they carry the most risk, because a regression there affects revenue and payment scope. Mark those for test coverage before you change anything else.

Record each extension with its owner, business purpose, source, installed version, last release date, supported version matrix, overlap with other extensions and the customer, order or payment data it touches. Then assign one decision. Keep an extension when its vendor confirms support for your target versions and the code passes review. Replace it when a maintained alternative covers the same function, particularly where two modules overlap on promotions or shipping. Remove it when no business process uses the feature. If you are considering a community distribution, Mage-OS describes itself as upstream compatible with Magento 2 extensions, but confirm compatibility for each extension in your own environment before assuming it carries over. Share the completed register with the team planning the upgrade so the test plan follows from it.

Which extension parts to inspect: modules, themes and the core they touch

Before judging any extension, an audit needs a map of what it changes. Magento Open Source extensions arrive as modules, themes or language packages, and each one attaches to the core through a small set of hook points that determine how much work an upgrade will cost.

Modules and their PSR-4 structure

Modules are the main unit of extension code. Adobe's developer documentation describes them as following a PSR-4 compliant structure, so each module's namespace should map cleanly to its directory tree. During the audit, list every module vendor and namespace, note which ones sit under app/code rather than Composer vendor directories, and flag any that are hand-copied into the codebase, since those rarely receive updates.

Themes and their template overrides

Themes control how storefront and admin pages look and which templates render them. An extension theme or a child theme may override core templates, and those overrides must be reapplied by hand after each upgrade if the core template changes. Inspect each theme's parent chain, its registration.php and theme.xml files, and every template or layout file it replaces, then record which overrides exist and whether the extension vendor still maintains them.

Plugins, observers and preferences

Plugins intercept public method calls, observers react to dispatched events, and preferences replace a class outright. Preferences carry the highest upgrade risk because a replaced class will not receive core fixes unless someone merges them. Search di.xml files for preference and plugin entries, and event declarations in events.xml, then note which core classes each one touches and whether a second extension targets the same method.

Layout XML, templates and the admin menu

Layout XML adds blocks, moves containers and changes which templates render on each page. Admin menus, system configuration sections and ACL resources are declared in their own XML files, and they can hide core settings or create new admin pages that must be reviewed for access rules. Check layout handles that touch checkout and payment pages first, then review menu.xml, system.xml and acl.xml for entries that expose sensitive settings to roles that do not need them.

GraphQL schema, cron jobs and scheduled work

Extensions can add GraphQL types, queries and mutations through schema.graphqls, and register background work in crontab.xml. Both expand the surface an upgrade must test: an extra GraphQL field can expose data to unauthenticated clients, and a cron job that runs every minute can load the database on a busy store. For each extension, list its schema.graphqls entries, its crontab.xml jobs and their schedules, and whether anything is documented as running in production.

Composer files and the registration chain

Every module must appear in composer.json or a path repository, be listed as enabled in app/etc/config.php, and load its registration.php file. These three places together define what the installation actually runs. Compare the module list in config.php with the packages in composer.lock and the modules reported by the console, because modules that are declared but disabled, or enabled but absent from Composer, are common sources of confusion during an upgrade. Confirm the exact file layout against the Adobe developer documentation for your version.

Keep, replace or remove: the decisions and trade-offs for each extension

This table compares the six options for each installed extension found in the audit, from keeping it unchanged to removing it. Read each row against three tests: whether the extension is still actively maintained, whether it is compatible with your target Magento Open Source version, and whether Magento core now covers the same function. The operational cost column shows what you take on with each choice, which is usually the deciding factor.

Decision	When it fits	Operational cost to carry
Keep as is	Actively maintained by its vendor, released for your target 2.4.x version, and not overlapping with core features or other extensions	Routine updates on each patch cycle, plus regression testing of the store flows it touches
Keep with a patch or fork	Still needed and maintained upstream, but a defect or compatibility gap blocks the target version and the vendor has not yet released a fix	Ongoing patch burden on every upstream release, a private code branch to maintain, and custom testing after each merge
Replace with a maintained extension	A current, actively maintained alternative covers the same business function with comparable configuration and data	Migration of settings and data, retesting of checkout, catalog and admin flows, and a vendor dependency on the new publisher
Replace with a custom module	No maintained extension fits, the function is core to the business, or the existing extension carries too much unrelated code	Custom code your team or partner must document, secure, upgrade with each Magento release, and test without vendor support
Merge overlapping extensions	Two or more extensions handle the same task, such as multiple shipping, reporting or content tools, and one can absorb the other	One-time consolidation and data cleanup, then a single configuration to maintain and a smaller test surface
Remove	The function is now provided by Magento Open Source core, the extension is abandoned, or no business process still uses it	Removal and data cleanup work, with the risk of orphaned database tables and configuration to confirm after uninstall

How to run a Magento extension audit step by step

This sequence turns an unknown set of third-party extensions into a signed keep, replace or remove decision for each one, so an upgrade or migration starts from a known inventory and tested compatibility results. Each step ends in an artifact that a reviewer can check.

Freeze an inventory from composer.json, config.php and the file system
Your team or the audit partner lists every third-party package in composer.json and the lock file, every module enabled in app/etc/config.php, and every folder under app/code and vendor that was not installed as core. Record the commit or build the inventory was taken from so it can be reproduced later. Compare the list with the module status output on a staging copy. The check is a versioned inventory file that lists each module name, package name and source path, with no unexplained entries.
Map each extension to a business function and owner
For each module in the inventory, name the business process it supports, such as tax, shipping rates, payment capture, product feeds or ERP sync, and name the person who approves changes to it. Store operations and finance usually know these answers better than the development team, so ask them directly. Extensions with no clear function or owner are the first candidates for review. The check is a mapping sheet where every row has a function and an owner, and every blank has been resolved or flagged for escalation.
Record vendor, version, license and last release date
Pull the vendor, installed version, license and date of the most recent release for each package from its repository or marketplace listing. Note whether the vendor still publishes fixes for the Magento release line you plan to run, and flag any license your legal team must review before the store is hosted for clients or shared with a partner. Where a listing is unclear, ask the vendor for written confirmation of compatibility with the target release. The check is a register with a complete row for every extension and no unknown license or release fields.
Diff against core overrides and preferences
Compare the codebase with a clean installation of the same Magento version to find classes that override core files, plugins that intercept core methods, and dependency injection preferences that replace core implementations. Each override is a likely point of failure during an upgrade, so note which ones come from an extension and which were written in-house. Use a standard diff tool against the clean copy and keep the output. The check is a diff report that lists every override and preference with its owning module, reviewed by the developer who will carry out the upgrade.
Run the compatibility tool and static analysis
Run Adobe's Upgrade Compatibility Tool against the target release, then run static analysis and coding standard checks across custom and third-party code. The combined output should show deprecated calls, insecure patterns and structural problems in one place. Treat the results as a triage list, since the tools cannot judge business logic. Attribute each finding to a module so vendors and owners can act on it. The check is a combined report in which every finding is marked as fixed, accepted with a written reason, or sent to the vendor.
Check payment, checkout and customer-data paths manually
On a staging store with test payment credentials, walk through checkout, payment capture, refunds, tax and shipping calculation, account creation, login, and any export of customer or order data. Automated checks miss logic errors on these paths, and they carry the highest risk for payment and personal data. Also record where each extension sends data outside the store and which Content Security Policy entries it depends on. The check is a signed walkthrough checklist with each path marked pass, fail or open, and every failure linked to a finding.
Test on a staging copy at target versions
Restore a recent copy of the production database and media to a staging environment that matches the PHP, database, search, cache, queue and nginx versions listed in Adobe's system requirements for the release you plan to run. Adobe supports only the listed combinations, so confirm each one before testing. Run full reindexing, cron jobs and the automated test suite, then repeat the payment and order flows from the previous step. Apply the same access controls to the copy as to production. The check is a test record with exact component versions and a list of failing tests, each assigned to an owner.
Score decisions and close with sign-off
Score each extension on business function, risk, upgrade effort and vendor support, then record a keep, replace or remove decision with a short reason. Removals go on a dated removal list, and replacements go into a backlog that names the function each one must cover and its owner. Business owners named in the mapping step sign each row before the change board schedules the upgrade or migration. The check is a signed decision register, a removal list and a replacement backlog that the business owners have approved.

What drives extension audit effort and how to keep it down

This table lists the drivers that change how much work an extension audit takes, why each one adds effort, and what you can do before the audit starts. Read each row against your own extension inventory, and ask any partner to itemize each driver in a written quote so you can see which items shape the total and which you can reduce yourself.

Driver	Why it raises effort	How to keep it down
Number of extensions	Each extension has its own code, release history, and compatibility with the target 2.4.x line that must be checked.	Remove unused extensions before the audit, consolidate overlapping ones, and provide a list with vendor, version, and last release date.
Depth of core overrides	Class rewrites and template overrides replace core behavior, so each one must be rechecked against the target release.	Ask for a list of overrides, prefer plugins where the extension allows it, and review high-risk overrides first.
Payment and checkout integrations	These handle payment data flow, Content Security Policy rules, and PCI DSS scope, so they need deeper review than most modules.	Scope the first pass to checkout and payment paths, and confirm each vendor's support for the target PHP version and CSP restrict mode.
Custom ERP or third-party connectors	Custom connector code often depends on API behavior and data mappings that no vendor documents, so it needs sync testing.	Obtain source code, the owner's name, and data mapping documents, then test with a set of sample orders, products, and stock updates.
Number of storefronts and languages	Each store view can carry its own extension settings, translations, and theme behavior, which multiplies the checks.	Test one representative store view per theme first, then sample the others against a short checklist of differences.
Documentation quality	Missing install notes, undocumented configuration, and unknown ownership increase the time spent discovering how each extension works.	Require vendor documentation and changelogs before the audit begins, and record any gaps as open items with a named owner.
Number of target versions tested	Moving to 2.4.9 means checking extensions against its listed PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, and Composer versions.	Fix one target version, check extensions against its requirement list, and use the Upgrade Compatibility Tool before adding more versions to the scope.

How the audit changes for single node, multi-node and migration targets

A single node store runs the web, database, search, cache and queue services on one host or one tightly grouped set of services that you manage together. The audit can be shorter because there is one runtime to test and one staging copy to compare against production. The main risk is not topology but drift: an extension that was installed for a quick fix and never reviewed. Focus the work on what the store actually does.

Practical checks for this target:

Clone production into one staging copy and run the full inventory there, including the module list, composer show output and any extension-owned cron jobs.
Compare the installed extensions against the current storefront and admin features to find modules that no longer serve a purpose.
Run a short set of runtime checks: admin login, checkout, a few catalog pages, and any scheduled jobs the extensions add.
Review each extension's declared PHP and Magento version constraints against the release line you plan to run.
Record the outcome for each extension as keep, replace or remove so the upgrade plan has a single list.

Confirm with each extension vendor which Magento Open Source versions and PHP versions they test against, and ask for a release history that matches your target line.

What to check for security in third-party extension code

Third-party extensions run inside the same PHP process, database and admin session as Magento core, so a weak extension weakens the whole store. The checks below cover the code paths and configuration most often reviewed during an extension audit, and they are meant to be run against each installed extension rather than treated as a one-time scan.

Unmaintained packages and unpatched dependencies

Check each extension's composer.json, release history and last commit date in its source repository, then compare its declared dependencies against the advisories published for them. An extension that has not shipped a compatible release for the Magento version you run, or that pins an old library, will not receive security fixes on its own schedule. Record the owner, the supported versions and whether a maintained fork or replacement exists before the upgrade decision.

Controllers exposed without ACL checks

Open each controller class and confirm that it declares an ACL resource and checks it, or that it is intentionally limited to anonymous customer or guest use with its own validation. Look for admin routes that accept requests without the ADMIN_RESOURCE constant or equivalent check, and for POST actions that change data without form key validation. Test each route as a guest, a customer and a low-privilege admin role, and record which requests succeed.

Unsafe file uploads

Review every upload handler for file type validation on the server side, not only in the browser, and for where the file is stored. Uploads saved inside a web-readable directory with an executable or unexpected extension create a path to remote code execution. Confirm that stored files are renamed, that the upload directory does not execute scripts, and that image processing libraries are current. Ask the vendor to show the validation code for each accepted type.

Direct SQL and raw query construction

Search the extension for raw queries built with string concatenation or variables from request parameters, and for calls to the database adapter that bypass the resource model and collection classes. Magento's query builder and bound parameters keep input separate from SQL text. Flag any query that interpolates user-supplied values, and confirm that custom tables are declared in db_schema.xml rather than created at runtime with ad hoc statements.

Unescaped output in templates

Inspect each phtml template for output that is not passed through the escaper, such as direct echo of request data, product attributes or customer fields. Verify that the template uses the escapeHtml, escapeUrl and escapeJs helpers in the correct context, and that block methods returning HTML are not rendered unescaped. Cross-site scripting in admin grids and storefront pages is often introduced in this layer, so include admin templates in the review.

Outbound calls to third-party endpoints

List every HTTP client call, webhook, remote script load and API endpoint the extension contacts, including the domain, the data sent and whether the connection verifies certificates. Compare this list with the purpose the vendor documents. Extensions that send customer data, order details or admin credentials to a remote service need a written data flow, a contract and a decision on whether that transfer is acceptable for the store and its payment scope.

Third-party scripts on payment pages

Where the extension injects JavaScript or iframes, check whether it does so on checkout, cart or payment pages, since Adobe documents that from 2.4.7 Content Security Policy runs in restrict mode by default on storefront and admin payment pages. Any extension script loaded there must be permitted by the policy you configure, and each added source should be reviewed for what it can read from the page. Document each allowed source and the business reason for it.

Credentials stored in configuration

Search core_config_data entries and extension config files for API keys, passwords, tokens and private keys stored in plain text. Confirm whether the extension uses Magento's encrypted configuration values and whether secrets are kept in environment variables or a secrets manager instead. Also check that credentials are not written to logs, exported in admin reports or exposed through configuration pages visible to lower-privilege admin roles.

Who can install and change extensions

Review which admin accounts can upload packages, run Composer, enable modules or change extension settings, and whether that access is tied to named individuals with two-factor authentication. Because an installed extension can run arbitrary code, the people who can add or enable one hold the highest trust in the store. Confirm that installation happens through a reviewed change process and that the audit log records each module enable or disable.

How to verify the audit held and failed extensions fail safely

The audit is only finished when you can prove its decisions held after the change. Start by reconciling three records: the post-change extension inventory, the decision log that recorded keep, replace or remove for each extension, and the output of the Upgrade Compatibility Tool run against the target Magento Open Source version. Every extension in the inventory should map to a logged decision, every removal should appear in the log as completed, and the compatibility tool output should be attached to the change record rather than left on a developer's workstation. Any extension present in the code but absent from the log, or logged as removed but still present in the composer manifest or the module list, is a finding that blocks sign-off. Confirm which inventory and compatibility tooling your team uses in its own environment, since the exact commands and report formats depend on your version and build process.

Next, run regression tests on staging built to the target PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and nginx versions, not the versions currently in production. Cover four flows end to end: checkout as a guest and as a logged-in customer, customer account actions such as registration, address book and order history, admin order creation and editing, and invoice and shipment generation. Include any payment method and any ERP or shipping integration that touches these flows, because a replaced extension often sits on the boundary between them. Automated browser suites are common for this, but the tool choice is yours to confirm with your QA lead. Record pass or fail per flow with the build identifier, so the evidence can be reproduced later.

Removed extensions often leave traces that a passing checkout test will not reveal. Check the layout XML and theme overrides for blocks or handles that still reference removed module names, review cron schedules for jobs that now point at missing classes, and search the configuration tables for orphaned keys under removed module paths. Run the cron group and confirm that no job errors on each run. Check the admin configuration pages for sections that no longer render or that save values to paths nothing reads. These checks are dull, but they are where upgrade incidents commonly start weeks after cutover.

Failure testing answers a different question: what happens when a replacement or retained extension stops working. On staging, disable each replaced extension in turn, then confirm that storefront category, product and CMS pages still return normally and that a guest checkout can still be completed, with the affected feature degraded or hidden instead of producing server errors. Then confirm that a failed extension does not take the admin down. Disable a module, load the dashboard, product grid, order grid and system configuration, and verify that the admin still signs in and that the error is logged rather than displayed to administrators as a fatal page. Record which features fail closed, such as a payment method that is hidden, and which fail open, which you should treat as a defect to fix before go-live.

Before sign-off, agree the acceptance criteria in writing with the internal owner and any implementation partner. The record should list each test, its result, the build and environment, the person who ran it, and the open defects with owners. Ask for the same evidence from anyone quoting the work, including the test scripts and the compatibility report, so the audit can be reproduced during a later upgrade or an assessor's review. Confirm with your security and payment team whether any payment page script or Content Security Policy change was part of the audit, since those changes need their own check after the extension changes.

What to monitor, document and re-audit after an extension decision

Choosing which extensions to keep is only the start. The six practices below keep the installed set known, supported and safe to upgrade, and each one feeds the next audit, so the register and change records should stay current between releases.

Keep an extension register

Record every installed extension with its owner, installed version, source (marketplace listing, vendor direct or in-house code) and next review date. The register is the starting point for every later check, and an extension without a named owner is rarely reviewed. Update it at each patch cycle and whenever a developer joins or leaves the team. Confirm that the register matches the code actually deployed to production, since drift between the two is common.

Watch vendor advisories and release notes

Subscribe the register's listed contacts to each extension vendor's release notes and security advisory channels, and track the core security releases Adobe publishes. Log every notice against the affected extension, the severity the vendor states, and the date your team acted on it. Record the last release date for each extension, because an abandoned module with no recent release is a risk even without a known vulnerability. Confirm who receives notices when a vendor changes contacts.

Run compatibility checks each patch cycle

Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, so treat each patch as a trigger for a compatibility check. Run the Upgrade Compatibility Tool against the target version and confirm each extension declares support for the PHP and service versions in use. Test checkout, customer account and payment flows in a staging copy, since extension conflicts often surface there first. Record the results against each register entry.

Document every core override

Any change that replaces or rewrites core behavior, whether through a preference, a plugin workaround or a copied template, needs a written entry. Record the file or class affected, the extension or business reason it exists, its owner and the test that proves it still works. Undocumented overrides are where upgrades stall, because the team cannot tell whether a later core change or extension update has made them obsolete. Review the list before each upgrade and remove overrides that are no longer needed.

Back up code and database first

Take a backup of the code base and database immediately before each extension install, update or removal, and tag it with the change ticket. Include the Composer lock file and environment configuration, not only the code tree, so the exact prior state can be rebuilt. Keep a tested restore path, because a backup that has never been restored is an assumption. Store copies away from the production host and confirm retention with your compliance owner, since backups may hold personal or payment-related data.

Re-audit before each 2.4.x upgrade

Schedule a fresh audit before moving to a new 2.4.x line, because each extension must be checked against the target PHP, database, search and queue versions. Plan around Adobe's end of regular support dates: August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Confirm the target release in Adobe's released versions list before booking the audit. Let the audit decide which extensions are kept, replaced or removed.

What buyers ask about extension audit cost, time and effort

What does a Magento Open Source extension audit cost?

An extension audit is priced from the written scope, not from a published rate card. DeployOpen does not publish a price list, and a quote follows once the scope is agreed in writing. The main cost drivers are the number of installed extensions, how many of them override core classes or templates, how many payment and checkout paths touch third-party code, and how many target Magento Open Source versions you need to test against. Each extra target version usually means another round of compatibility testing. Ask the partner to show the cost by workstream (inventory, code review, compatibility testing, replacement recommendations and the written report) so you can see where the effort sits and what you could reduce yourself.

How long does an extension audit take?

Duration depends on scope, and DeployOpen confirms the timeline in the fixed-scope agreement before work starts. The biggest factors are the extension count, the depth of review per extension, whether core overrides need line-by-line reading, and how quickly your business owners can rule on keep, replace or remove decisions. Staging availability matters too, because compatibility checks cannot run without a working copy of the store. Ask for a timeline that separates discovery, code review, testing and reporting, and confirm which dependencies (access, test data, sign-offs) sit on your side and would move the schedule if they slip.

What does our internal team need to provide during the audit?

Plan for four inputs. First, business owners who can decide which features stay, change or go, because an extension audit ends in those decisions. Second, admin and repository access, including composer metadata, the list of installed modules and any private extension source. Third, a staging environment that matches production closely enough to test checkout, payments and integrations. Fourth, realistic test data and order scenarios, such as refunds, tax rules and multi-currency orders. Ask the partner to list each input with an owner and a due date in the quote.

Can our in-house team run an extension audit alone?

Yes, an experienced in-house Magento team can inventory extensions, check versions, read changelogs and run a compatibility test on staging. Specialist review is usually worth buying for the parts that need independent judgment: security review of code that handles payment data, customer data or admin authentication, assessment of core overrides that could break on upgrade, and checks on extensions that call external services. Your team also benefits from a second opinion on the replace-or-remove list, since extensions often overlap with core features or with each other.

What should we ask a partner to itemize in a fixed-scope quote?

Ask for a written breakdown that names every deliverable and who performs it. Useful line items include the extension inventory and version list, the number of extensions reviewed in depth, the core override review, security and code quality findings, payment path testing, compatibility testing per target version, the keep, replace or remove recommendations, the written report format, and the retest after fixes. Also ask what is excluded, such as replacement development, data migration, hosting changes and ongoing patching. Confirm the acceptance criteria and how changes to scope are priced before work starts.

Does the audit cover security as well as upgrade compatibility?

Yes, a well-scoped audit covers both. Security review looks at how each extension handles input, authentication, file uploads, payment data and outbound calls, while compatibility testing checks whether it still works on the Magento Open Source version you plan to run. Ask the partner which security checks are included and whether they follow an established secure coding reference. Note that DeployOpen prepares evidence and findings for compliance assessments but does not issue audit reports or certifications, so independent assessors remain responsible for any formal attestation.

What happens after the audit report is delivered?

The report becomes the basis for a decision list, not a finished project. Your team or a partner then removes or replaces extensions, fixes findings, retests on staging and schedules the upgrade or migration. Ask whether remediation is included in the audit price or quoted separately, and whether a retest after fixes is part of the fixed scope. Ongoing compatibility checks for each Magento patch release can be handled through a retainer if you want continuous coverage.

How DeployOpen works on this

DeployOpen reviews the third-party extensions in your Magento Open Source store against the release you plan to run, then recommends keep, replace or remove decisions in writing. Work runs inside your own infrastructure, and each engagement is fixed-scope with agreed deliverables before any review begins.

How we scope

Agree in writing which extensions, modules and themes are in the review and which Magento Open Source release is the target
Confirm the inventory source, such as composer.json, app/code and the admin module list, before any review starts
Define the criteria for each decision, covering security, code quality, upgrade compatibility and functional overlap
Name the business owner who signs off keep, replace or remove calls for each extension group

How we build

Check each extension against the target PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and RabbitMQ versions in the Adobe system requirements
Run the Upgrade Compatibility Tool and a test upgrade in a non-production copy of your environment
Review extension code for security issues, unsafe patterns and PSR-4 module structure, and record findings with file references
Map overlapping extensions that change the same checkout, catalog or admin behavior, and flag conflicts that break after upgrade

How we hand over

Deliver a decision register listing each extension, its finding, the recommended action and the owner who approved it
Document replacement candidates, removal steps and any custom code that depends on a retained extension
Provide a rollback plan and the test cases used to confirm storefront, checkout and admin behavior after each change
Hand over the audit in your repository and ticketing system so your own team can maintain it after the engagement

How we support

Offer ongoing support as a retainer to repeat the extension review each time you move to a new patch or minor release
Re-check extensions when Adobe ships security patches, since each patch cycle can change compatibility
Confirm with each extension vendor which versions they support before you commit to an upgrade date
Ask for the retainer scope and the review cadence in writing before you sign