I have been talking to several companies recently who are running Akeneo Community Edition and asking the same question: "okay, but when does this actually become a problem?"
The honest answer is that nobody is going to pull the plug on your server overnight. Akeneo CE technically works. Releases still appear on GitHub. But the question is not "does it work today" - it is "do I want to build on this for the next 3-5 years, knowing the vendor has effectively turned its back on this product and focused all energy on paid SaaS".
If the answer is "no" - this article is for you. I break down the migration to UnoPIM into concrete stages, including what actually causes problems, not just the happy path from the documentation.
Before you start: what you need to know about architectural differences
Akeneo CE and UnoPIM solve the same problem - product information management - but do it differently under the hood. A few things that matter for migration:
Framework. Akeneo is Symfony, UnoPIM is Laravel. For data migration this does not matter much. For rewriting integrations - it matters a lot, because both systems expose very different APIs.
Infrastructure. Akeneo requires Elasticsearch for product search and indexing. UnoPIM has no such requirement - it runs on a standard MySQL + Redis stack. If your hosting was sized for Akeneo, after migration you can simplify it and likely reduce the cost.
Data structure. Both systems have the concept of product families and attribute groups. Mapping is usually 1:1 for standard structures. Problems appear with very complex enterprise attribute types - but if you are on CE, you do not have those anyway.
Stage 1: Audit what you have in Akeneo
Do not start exporting data before you have a complete picture of the structure. This is the most common mistake - someone dumps a CSV and only during import discovers they have 47 attribute types, half of which are duplicates from different eras of the catalog.
What you inventory:
Product families - how many you have, whether they overlap, whether they are actively used. In older Akeneo deployments you often find families created for specific projects that have had no products assigned for years.
Attributes and attribute groups - types, required flags, family assignments. Check whether you have global attributes that should be channel-specific or vice versa.
Channels and locales - how many languages and markets have data. This directly affects migration complexity.
Data completeness - what percentage of products have required attributes filled. Migration does not fix incomplete data - it moves it in the same state.
A good audit tool is Akeneo's native CSV export - export families and attributes separately before touching the products. This gives you the full picture without a 40GB file of the entire catalog.
Stage 2: Mapping structure to UnoPIM
This is the stage that takes the most time and where the biggest mistakes happen. It is not about technical field-to-field mapping - it is about design decisions.
A few things worth thinking through before you start configuring UnoPIM:
Are you copying 1:1 or cleaning up along the way? Migration is a good opportunity to clean up legacy mess - merge duplicate families, standardize attribute naming, remove what nobody uses. But this extends the project. If time is the priority, do a 1:1 migration first and leave cleanup for later.
Attribute types. UnoPIM supports: text, textarea, number, boolean, select, multiselect, date, datetime, image, gallery, file, price. If you have non-standard types in Akeneo (e.g. metric with unit), you need to decide how to represent them in UnoPIM - typically number + a separate select for the unit.
Validations. Akeneo CE lets you define validations at attribute level (regex, min/max, required per channel). UnoPIM has equivalent mechanisms but configures them differently. Do not assume they transfer automatically.
Stage 3: Export from Akeneo
You have two paths: CSV or API. Which is better depends on catalog size and how much precision you need.
CSV is simpler to implement and sufficient for most migrations. Akeneo generates CSV files with the full structure of products, attributes, and associations. Weakness: media (images, files) are not in CSV - you handle them separately through a media package export or direct storage access.
Akeneo REST API gives full control and handles product associations and media better. It requires writing an import script, but for catalogs above 10,000 SKUs and multiple channels the investment is worth it.
Regardless of path, export in this order:
Attributes and attribute options (select values)
Product families
Categories
Simple products
Products with variants (product models in Akeneo)
Media
Product associations
Order matters - on import, UnoPIM needs to know families before you import products into those families.
Stage 4: Import into UnoPIM and validation
UnoPIM accepts imports through the admin panel (CSV) or API. On the first import there are almost always a few errors - this is normal, do not panic.
Most common import issues:
Encoding. If your catalog has non-ASCII characters and you export from Akeneo to CSV, make sure the file is UTF-8 without BOM. Windows likes to add a BOM which breaks the first column.
Select options. UnoPIM requires select attribute options to exist before you import products with those values. If you import in the wrong order, you get validation errors on products.
Media. Images are imported separately - either via URL (UnoPIM fetches them) or direct upload. For large catalogs, URL import is more convenient but requires the old Akeneo server to still be accessible during migration.
After the first import I always run the same validation checklist:
Product count in UnoPIM = product count in Akeneo
Random sample of 20-50 products - manual field-by-field comparison
Products with variants - are variants correctly linked to their parent
Media - are main images and gallery correctly assigned
Channels - is data present for every language and channel
Stage 5: Reconnecting integrations
This is the stage that hurts most - especially if you have an old Akeneo-PrestaShop integration written by someone who is long gone.
UnoPIM exposes a REST API with its own endpoint structure. It is not compatible with Akeneo's API - you need to write a new connector on the store side. If you are running PrestaShop, there is good news: there is an official UnoPIM connector for PrestaShop that handles basic synchronization of products, categories, and attributes. This is a solid starting point - in practice most implementations require extending it to cover specific store requirements (custom field mapping, sync schedules, variant handling), but you are not starting from scratch. In practice this means:
A new module/plugin on the PrestaShop or Bagisto side that reads from UnoPIM API instead of Akeneo API
Mapping UnoPIM fields to store fields (endpoint names and JSON structure differ)
Rewriting sync logic (triggers, schedules, error handling)
Best practice is to run UnoPIM in parallel with Akeneo for 2-4 weeks. Data is synced to both systems, the new store connector is tested in a staging environment. Only after confirming everything works do you switch production and shut down Akeneo.
Where things most commonly go wrong
Three things I see most often as a source of delays:
Underestimating attribute count. "We have around 50 attributes" - I hear this often. After the audit it turns out to be 180, of which 40 are duplicates from different stages of the catalog's life. The audit always takes longer than expected.
Media without structure. Images in Akeneo CE can be stored in different locations depending on version and configuration. During migration it turns out some media is on local disk, some on S3, some is not reachable at all. This blocks the import.
ERP integrations written specifically for Akeneo. If your ERP sends data directly to Akeneo through a custom script - that script needs to be rewritten for UnoPIM API. Often it turns out nobody has documentation for that script and it needs to be reverse-engineered.
How long it realistically takes and what it costs
For a catalog of 1,000-10,000 SKUs, one language, one store integration and ERP - realistic time is 5-7 weeks. Broken down:
Weeks 1-2: Akeneo audit, UnoPIM structure design
Weeks 3-4: UnoPIM configuration, data import, validation
Weeks 5-6: new store connector, staging tests
Week 7: parallel operation of both systems, production testing, switchover
Larger catalog, more languages, more channels - multiply accordingly. A migration with a complex ERP and several marketplaces can easily take 3 months.
If you want to see how the cost compares to staying on Akeneo CE or moving to a paid plan - I have an interactive TCO calculator on the service page.
Does this make sense for your business?
Migration makes sense if:
You are planning new integrations or channels in the next 12 months - and do not want to build that on a platform without active development
Your Akeneo infrastructure cost (Elasticsearch, devops) is noticeable
You want to use UnoPIM's AI features (32 commands, your own LLM key) - Akeneo CE does not have this
Migration does not make sense if:
Your catalog is stable, integrations work, you are not planning anything new - CE will hold up fine for a few more years
You have an in-house Symfony team that knows Akeneo inside out - switching platforms is a learning cost for them
Have a specific catalog and wondering whether migration makes sense? Write to me - the first conversation is free and does not end with a proposal if it does not make sense. Contact →
