Why are Magento extension providers charging extra for enterprise versions of their modules?

I have a pretty good idea that the codebase for both of the module versions will be identical so where does this extra cost come from? In some cases i have seend > $100 for the enterprise version.

Is this:

  1. An extra cost due to extra technical complexity (i cant see what that would be)
  2. An extra cost due to Magento licensing somehow
  3. Profiteering since enterprise clients are likely to be able to pay more
  4. Something else?
  • I think it is a combination of 1 and 3 plus that enterprise customers are on average more demanding, requiring higher quality, report more bugs etc. – Paul Hachmang Aug 28 '13 at 17:45
  • 5
    Answers to this question may likely be opinion-based, but leaving open for now hoping that some extension developers will chime in. – benmarks Aug 28 '13 at 18:49
  • Thats what i was hoping for also – Marty Wallace Aug 28 '13 at 19:16
  • Easy answer. To develop for Enterprise, you must own enterprise. The cost gets passed on. Deal. – Fiasco Labs Jul 16 '14 at 14:39

I am an extension provider working with Enterprise, and wanted to share some of the reasons that are behind the decision to charge more for an Enterprise version extension.

To be able to officially offer Enterprise version extensions on Magento Connect (and to access the testing versions), you need to be a Magento partner. This incurs a yearly fee with an entry level of $10.000 per year. There are a couple of different ways to look at how to absorb this cost, and it's not always fair to raise the price of Community extensions (though it's a far bigger market) simply to be able to officially offer an Enterprise version extension. Enterprise is a fairly small market, so the cost of entering and serving this market is spread across fewer people.

From a technical standpoint there are differences - Philwinkle already mentioned a few. I would also add to that list the range of custom totals that come out of the Enterprise features (like points, credit to account, etc), staging sites and restrictions, additional promotional capabilities - depending on what an extension does, these all need to be considered. Additionally, Enterprise releases never seem to follow Community releases one to one - so the codebase might be fairly similar, but it does not match.

In my view, supporting a given version of Magento (Community or Enterprise) means that you need to test the extension against this version and be prepared to answer/troubleshoot all support questions that may arise. Any quality extension will always be tested extensively on all versions that it officially supports.

In terms of our own process, once we have made sure that an extension works on Enterprise, and supports the Enterprise features you would expect, this extra effort is oncharged in the way of a higher Enterprise extension price (a cost that's not always fair to pass onto Community customers). Technically you might be able to install Community versions of some extensions on Enterprise, however this would not be officially supported and does not come with the guarantees of having being tested and compatible with all features.

  • 1
    And it's good to point out that the testing referred to here can be pretty time intensive. Front end facing functionality of cached pages have three times the number of test scenarios due to just the full page cache. :) – davidalger Aug 29 '13 at 2:37

TL;DR; Software pricing is complicated, the answer to your question is all of the above.

While Magento Community edition and Magento Enterprise Edition are very similar, there are differences in the two platforms. Does the extension work with EE's full page caching? I ran into an EE bug with Commerce Bug (the Magento debugging extension my business sells) where it wouldn't work with a version of EE's private sales feature. Beyond these specific examples, an extension business needs to look at the fact there are differences, and those differences will incur either additional development time, or additional support time.

It also means an extension business that's providing EE support needs to have access to a copy of Enterprise Edition. If an extension developer is on the up and up that means a partnership of some sort with Magento Inc. which is a cost — both in fees and in maintaing that relationship.

Finally, what you call profiteering another business might call price differentiation. The murky truth is somewhere in-between.

As a very small business owner selling extensions, I've thought about charging more for Enterprise Edition support — but at the end of the day my support workload didn't have a lot of Enterprise Edition related questions, and a significant portion of my customer base are developers who actually like working with me to solve the problems encountered. Even for customers who aren't developers, the fact I'm willing to jump into their system to solve EE specific bugs (or CE bugs for that matter) leaves them feeling good about their purchase and they're more likely to buy from me in the future. It even occasionally leads to a small consulting gig.

That said, I can easily see how a larger scale extension developer selling to a less technical audience would need to raise EE prices to help keep their business afloat and growing. Like I said, software pricing (and business in general) is complicated.


A subjective question really requires a subjective answer. I'm not sure that this question will remain open; but I'll bite:

In my experience with two VERY LARGE Magento module developers, the main reasons were the following technical/dev challenges:

  • Full page cache hole-punching
  • Customer persistence
  • Customer segmentation
  • Admin logging
  • Order archival (impacted a sales report module)

And the following economic/social challenges:

  • The vendor pays a fee to be a "partner" and have access to dev and test on Enterprise Edition and must recoup this cost somewhere
  • EE installs typically have higher traffic, sales volume, and present a larger risk to the company to install 3rd party modules. Extra effort in testing and implementation (in either CE/EE version) is likely required on behalf of the company
  • EE clients are "sticky"; they don't give up on issues as easily. They often have much more highly customized environments and they demand more support time. In general they tend to have higher expectations.

Lastly - a word of advice:

Most any CE module that does not attempt to duplicate EE features should be able to be installed in EE. But, from experience, most extension developers will not support or warrant that module being installed on the EE store.

When you're facing down a full page cache hole-punching issue you'll really want that support and you'll likely have spent larger than $100 of time and lost revenue or developer frustration to warrant having spent it ahead of time.

  • 1
    Can I ask what exactly is full page cache hole-punching? What problems related with full page cache may occur when you want to convert CE extension to EE extension? – zitix Aug 28 '13 at 20:02
  • Think about it - if someone logs in on the frontend and your theme has a "Welcome Zitix" message on it - the cached page would always display "Welcome Zitix" to all subsequent visitors regardless of their name. Hole-punching allows you to define regions that are cached separately and assembled into the page at the time of the request. – philwinkle Aug 28 '13 at 20:22
  • Regarding full-page cache, it is often the case that one developer's duties don't include dealing with cache issues, it can often be more of an IT/server/hosting thing. Providers tend to specialize, and issues like these mean you not only have to get a developer involved, but also a server admin (possibly from a different company) and they may have to coordinate cache flushing during testing, eating up two peoples' time instead of just one. – pspahn Aug 29 '13 at 6:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.