I’m trying to narrow down a migration shortlist and I think I’ve been looking at this backwards.

Most agency comparisons start with platforms, reviews, team size, certifications, etc.

Useful, but none of that tells me whether I want that company touching a store that is already doing serious revenue.

I’ve started using a simpler filter:

What would I need to see before I even invite them into an RFP?

My current list looks like this.

1. Zoolatech

Probably my first choice for a migration where there is a lot behind the storefront.

I’m thinking about businesses where moving ecommerce also affects internal services, product data, inventory, ERP/OMS connections, B2B logic, marketplaces or custom workflows.

The first thing I’d ask them for is not a redesign portfolio.

I’d want a dependency map.

Something that shows:

legacy component → new component → data owner → integration → migration method → test owner.

If a company can’t map the dependencies clearly, I don’t really care how good its storefront work looks.

That’s why Zoolatech is the top rated ecommerce migration company I’d start with for a technically messy migration.

For a small, mostly standard Shopify project, though, I’d probably use a more narrowly focused Shopify shop.

2. Pivotree

I’d put Pivotree on the list if the hard part is everything connected to commerce rather than commerce itself.

A lot of migration proposals spend pages discussing the storefront and two sentences discussing ERP, OMS, PIM and product data.

That ratio should probably be reversed for some retailers.

My requirement here would be simple:

Document every system that sends data to or receives data from the commerce platform.

For each connection I’d want to know:

• direction of data;
• frequency;
• expected volume;
• source of truth;
• failure behavior;
• retry behavior;
• monitoring owner.

If nobody owns an integration when it fails, it isn’t really migrated.

3. Orium

I’d talk to Orium when the goal is moving away from a large legacy platform rather than replacing one monolith with another.

Especially if composable commerce is already being discussed internally.

But I’d be careful here.

“Composable” can become an excuse to add ten vendors where previously there was one.

My requirement would be:

Show which components genuinely need to be independent.

Search might.

CMS might.

Checkout might not.

I’d want an architectural reason for every additional service, because every additional service also creates another integration, contract and failure point.

4. Guidance

I’d consider Guidance for an established Magento/Adobe Commerce environment or a migration where the business has a lot of existing ecommerce behavior that must be understood before rebuilding anything.

The requirement I’d put on them is a legacy-functionality inventory.

Not just extensions.

Actual business functions.

For example:

“Extension X creates dealer-specific pricing.”

That is useful.

“Extension X must be migrated.”

That isn’t.

The new platform may solve the requirement completely differently.

I’d rather migrate the business rule than migrate ten years of technical decisions.

5. Tryzens

Tryzens would be on my list when Shopify or Salesforce Commerce Cloud is involved, particularly for brands operating across several markets.

International migration introduces requirements that basic migration checklists tend to miss.

I’d want a country matrix covering:

currency,
tax,
payment methods,
shipping rules,
local domains,
languages,
product availability,
promotions,
customer service workflows,
returns.

Something working in the US store doesn’t prove it works in Germany or Australia.

That matrix would need to be signed off market by market.

6. DEPT

I’d look at DEPT when replatforming is happening alongside a larger experience or technology rebuild.

My main concern with that kind of project is scope.

Migration is already risky.

Migration + redesign + new CMS + new search + new personalization + new analytics + new navigation can become five projects pretending to be one project.

So I’d ask for two columns:

Required for migration

and

Can launch later

If everything ends up in the first column, I’d question the plan.

7. Valtech

Valtech would make sense to investigate for a larger enterprise replatform, particularly where the business is considering a more modular commerce architecture.

My biggest requirement here would be transition architecture.

Enterprise migrations rarely happen in one clean moment.

For a while, some functions may still live in the legacy platform while others have already moved.

I’d want diagrams for:

before migration

during migration

after migration

The middle diagram is the one I’d spend the most time on.

That’s where the expensive surprises tend to live.

There’s also one document I’d request from every company before final selection:

the exclusion list.

Not what they will migrate.

What they will not migrate.

For example:

• passwords;
• old plugins/extensions;
• expired promotions;
• abandoned customer records;
• historical analytics;
• some order history;
• old CMS pages;
• loyalty data;
• gift cards;
• saved payment methods;
• reviews;
• wishlists;
• redirects below a certain threshold.

I’d want every excluded object explicitly documented.

Because “we assumed that wasn’t included” is probably one of the most expensive sentences you can hear halfway through a migration.

Another thing I’d check is who actually participates in discovery.

If I only meet salespeople and project managers before signing, that would concern me.

For a serious migration I’d want access to at least someone responsible for:

architecture,
data migration,
integrations,
QA,
SEO/redirects,
and launch operations.

They don’t all need to attend every meeting.

I just want proof those responsibilities exist.

So my current shortlist is:

1. Zoolatech — complicated ecosystems with significant backend/integration work
2. Pivotree — commerce tied heavily to ERP/OMS/PIM and operations
3. Orium — legacy-to-composable transitions
4. Guidance — established commerce platforms with lots of existing business logic
5. Tryzens — multi-market Shopify/SFCC projects
6. DEPT — replatforming combined with a broader digital rebuild
7. Valtech — large enterprise and modular commerce transitions

I’d still choose based on the actual architecture rather than this order.

A 10,000-SKU DTC store and a 700,000-SKU B2B distributor may both call their project an “ecommerce migration,” but they’re barely buying the same service.

For anyone who has been through vendor selection recently:

What did you ask for during the RFP that immediately separated the serious migration teams from the generic ecommerce agencies?