Work · Guilherme Di Paula

Migrating an enterprise DTC operation to Adobe Commerce

Replacing the platform of a multi-brand operation without stopping sales, inside a larger systems integration program.

Multiple brands · ERP (SAP), payments, logistics, CRM · 2025–2026

Context

A multi-brand DTC operation running on a SaaS platform had to move to Adobe Commerce as part of a larger post-acquisition systems integration program. The target platform was already set by the group standard. The job wasn’t choosing the technology: it was swapping the engine without stopping sales, with the catalog, the customer base and integrations with ERP, payments, logistics and CRM.

The hard decision

Early on, I spent energy trying to reopen the platform choice. It was the wrong fight. What threatened the migration was the operating model: integration and frontend release cycles out of sync, product data with no owner, irreversible decisions passing as technical tasks. I shifted the focus there.

What we did

We forced the contingency decision early. The possible scenarios for the cutover date went to the executive table weeks ahead, instead of the crossroads showing up the day before, when all that’s left is consequences.
We set objective acceptance criteria before cutover, and tied the go-live to them, not to the calendar.
We built the safety net before we needed it: a cutover plan in three blocks (before, during and after), a war room, 30 days of hypercare and an open channel for the business to report issues, with a response to every report.
We went live in phases. The store switched over in an overnight window, and completion was only declared once the ERP integration had stabilized, in September 2026.

What I learned

The platform is the most visible part of a migration and rarely the riskiest. The risk lives in the operating model and in the legacy knowledge held by a few people. And an irreversible decision needs a different process: the cutover with no way back got a different ritual, not more speed.

From operating on someone else's platform to owning it

Bringing e-commerce operations in-house and switching from a logic of serving demand to one of proposing.

3 e-commerce sites · outsourced support → in-house team · 2026

Context

Support and maintenance of the e-commerce platforms were outsourced. The internal team took requests, passed them on and chased deadlines. Operations ran, but nobody in-house had the full map of how the platforms behaved, so nobody could propose anything beyond what had already been asked. The transition to an in-house team was approved in 2026.

The hard decision

Bring it in-house, with temporary reinforcement on a fixed term, instead of swapping one vendor for another. A swap would have been faster and less risky in the short run, but it would have kept the same model: operating on someone else’s platform. The bet was that whoever owns, measures; whoever measures, proposes.

What we did

We designed the handover as a product, not an event. Documentation delivered every day rather than at the end, with a sample validated before scaling it. Then side-by-side shadowing, a progressive handback of roles and autonomous operation with the previous team on standby, through to revoking legacy access.
We named out loud the risk nobody writes down: the behavior of the people leaving during the transition, with a mitigation plan like any other risk.
We created a monthly platform review forum, which is not a project review. It opens by reporting back on what was asked at the previous edition before showing any new number, and every request becomes a backlog item with a business owner and a date.
We separated the front doors: new demand comes in through the product team, incidents through support, and leadership only decides priority across products.

What I learned

Ownership changes the conversation with the business: the team stops explaining why something couldn’t be done and starts showing up with numbers and proposals. I also learned that an executive forum needs an asynchronous path, a one-page summary plus the recording, because decision-makers’ calendars are never guaranteed. And that numbers come before adjectives.

Applied AI in production, not in pilot

Tools that take hours of work off the operation and turn "optimize for AI" into tickets with an owner.

2 tools in use · campaigns and GEO

Context

AI in e-commerce tends to stall at the pilot. The bar here was different: only what becomes part of the team’s routine and takes real work off the operation counts.

The hard decision

Deciding what not to automate. The temptation was to put AI on top of processes as they were. We went the other way: understand the process, simplify it, and only then automate. Automating a bad process just makes the error happen faster.

What we did

An internal no-code campaign platform. The business team now builds its own campaigns, with no ticket queue to engineering. Setup dropped from 20 hours to 1 hour, and engineering moved off the critical path to look after the platform.
A GEO tool I built and the team uses, that assesses 48 signals of how readable an e-commerce site is to AI engines. It’s deterministic: the same site produces the same result, so it can be compared month over month.
Diagnosis that turns into work: every finding becomes a ticket with severity, a suggested owner (development, content or e-commerce) and evidence. “Optimize for AI” stops being an intention and becomes a backlog.

What I learned

The first finding changed the question: the problem wasn’t whether AI crawlers could get into the site, but whether they could understand what they found. And a tool that becomes the yardstick has to say when it couldn’t measure. Failing silently is worse than not measuring.