Magento · 19 August 2026 · 10 min read
Every extension you install in Magento is a debt you repay at upgrade time
An extension costs a hundred euros today and holds you back in two years. How to choose, what to ask before buying, and what to do with the ones you already have.
The extension ecosystem is the main reason Magento gets chosen over a closed platform. It's also the main reason Magento stores end up stuck on old versions.
Both are true at the same time, and what separates them is how you choose.
Why an extension is a debt, not a purchase
When you buy an extension, you pay once. But you commit to something long-term: at every Magento update, somebody has to verify it still works. If the vendor hasn't released a compatible version, you have three options, all of them costly.
- Wait — and postpone the upgrade, which means postponing security patches too.
- Pay somebody to port it — usually more than the extension cost in the first place.
- Give up the functionality — and explain to the team why something they'd got used to no longer works.
In an upgrade, the blocker is almost never Magento. It's the three extensions with no new version.
Seven questions before you buy
| Question | Good signal |
|---|---|
| When was it last updated? | Within the last six months. Over a year, treat it as abandoned. |
| Has it released a version for the latest Magento? | Yes, within a few weeks of release. |
| Is there a Hyvä-compatible version? | Yes, or at least announced. Otherwise it blocks you at migration. |
| How many other extensions does it depend on? | As few as possible. Each brings its own debt. |
| Does it modify database tables? | If so, uninstalling becomes difficult. Ask how it's done. |
| What happens if I disable it? | The store works, just without that feature. |
| Is there public code to read? | Yes. Obfuscated or encrypted code is reason enough to refuse. |
The rule we apply
Before installing anything, one question: what happens if we don't? If the answer is “it would be nice”, it doesn't get installed. An extension justifies itself only when it solves a problem costing measurable money.
The second rule: we prefer a feature built simply, in our own code, to an extension bringing fifty features of which we use one. Our own code we maintain, and it breaks predictably. An extension breaks when somebody else decides it does.
What to do with what you already have
Almost any store a few years old carries extensions nobody uses any more. They're pure cost: they slow things down, enlarge the attack surface, and block upgrades.
- Take the inventory. The complete list, with version and the vendor's last update date.
- Mark what's no longer used. Ask the team, don't assume. You'll be surprised how many there are.
- Disable them on a test environment, not in production. See what breaks.
- Remove for good whatever passed the test, including the leftover tables.
- For what remains, note the status: maintained, abandoned, to be replaced. That list is your upgrade plan.
Those steps are exactly what we do in the code audit, and it's usually the first time the owner sees what is actually in their store.
The connection to speed
Every extension that touches the frontend adds its own JavaScript and CSS. Ten extensions means ten sets of baggage, loaded on every page, whether or not they're used there.
That's why stores with many extensions gain the most from moving to Hyvä: not only does the old stack go, but the migration forces the extension inventory — and usually half of them don't survive it, because nobody can find a reason to keep them.