Omeka Classic or Omeka S: How to Choose

Every few weeks someone asks us the same question, usually with a note of apology attached, as though they ought to already know the answer: should we be on Omeka Classic or Omeka S?

It is a fair question and a genuinely difficult one. The two share a name and a philosophy, and both are excellent at what they do. But they were built a decade apart for different kinds of institutions, and choosing the wrong one means either fighting the software or migrating later. Neither is fun.

Here is how we talk it through with libraries, archives, and museums who ask.

The short version

Omeka Classic is for one site with one collection. It is mature, well documented, and has a plugin and theme ecosystem built up over more than fifteen years. If you are putting a single exhibit or a single archive online and you want it working this month, Classic is often the faster road.

Omeka S is for many sites drawing on one shared pool of items. It was designed for institutions that need to publish several distinct sites — a departmental exhibit, a finding aid, a class project — without duplicating the underlying records. It also takes linked open data seriously in a way Classic does not.

If your answer to "how many sites will this eventually be?" is one, look hard at Classic. If it is I do not know yet, but probably more, look hard at S.

Where the difference actually bites

That summary is true but a little abstract. In practice, the choice shows up in four places.

Item reuse. In Classic, an item belongs to the site it lives in. In S, items live in a shared pool and any number of sites can pull from it. If you have a photograph that belongs in the town history exhibit, the annual report, and a student's class project, S lets that be one record. Classic makes it three, and three records drift apart over time.

Metadata discipline. Classic ships with Dublin Core and expects you to work within it. S lets you define and mix vocabularies, and it treats properties as real URIs rather than labels. This matters enormously if you plan to share data with a consortium or a state digital library, and it matters not at all if your collection will only ever be read by humans on your own website.

Theming. Classic themes are simpler and there are more of them. S themes are more capable but there are fewer, and the ones that exist assume you know what you want. Institutions with a strong visual brand often end up commissioning a custom theme either way, but the starting point in Classic is closer to finished.

Modules and plugins. Classic's plugin directory is deeper because it is older. S's module directory is growing and, importantly, is where new development is happening. If you need something specific — a particular import format, an unusual display — check both directories before you commit, because the presence or absence of one plugin can settle the question on its own.

Questions worth asking before you decide

We usually start here rather than with the feature comparison.

Who is going to maintain this in three years? Not who is building it now — who is answering the email about it in 2029. If the answer is a single part-time staff member, Classic's smaller surface area is a real advantage. If it is a digital initiatives team, S rewards the attention.

Does anything outside your organization need this data? Consortium harvesting, a state aggregator, a discovery layer, a partner institution. If yes, S's linked data support stops being an abstraction and starts being the reason you chose it.

Is this one project or the first of several? This is the question that decides it more often than any other. Institutions almost never build just one Omeka site. They build one, it goes well, and someone in another department asks for theirs. Classic handles that by installing Classic again. S handles it by adding a site.

What is your timeline? If a grant deadline is in eight weeks, that is a real constraint and Classic's shorter runway is worth something.

The migration question

People often ask whether starting on Classic and moving to S later is a reasonable plan. It is possible, and there are tools that help, but be honest with yourself about the cost. A migration is not just moving records: it is remapping metadata, rebuilding the theme, re-teaching staff, and fixing every URL you have already put in a newsletter. Institutions that do it rarely regret ending up on S. They frequently regret not going there first.

That said, "we will migrate eventually" is a much better plan than "we will not launch until we are certain." A live Classic site serving patrons beats a perfect S site that never got funded.

You do not always have to choose

One thing worth saying plainly, because it surprises people: you can run both. Plenty of institutions have a long-standing Classic site that works fine and no reason to touch it, alongside a newer S installation for everything going forward. The old exhibit keeps its URLs and its audience; the new work gets the better foundation.

The reason this comes up so often for us is that managing two platforms usually means two sets of server requirements, two upgrade cycles, and two admin interfaces to remember. That is the friction that made us build a single dashboard for both — not because running both is wrong, but because it should not cost you double the maintenance.

If you are still stuck

Write down the sites you expect to have in five years. Not the ones you are certain of — the plausible ones, including the department that has not asked yet. If that list has one item on it, you have your answer. If it has four, you have a different one.

And if you want a second opinion on your specific collection, we are happy to talk it through. We have no stake in which platform you land on. We host both.