Migrating Ole Henriksen: What Managing a Full Platform Overhaul Actually Looks Like

The Setup

Ole Henriksen is a cult-favorite skincare brand with a loyal customer base, a strong visual identity, and a digital presence that needed to catch up with both. When they came to us, the goal was clear on paper: migrate the site from Salesforce Commerce Cloud to Shopify Plus, redesign the experience from the ground up, and build a CMS back-end their internal teams could actually own going forward.

On paper, that's a significant but manageable project. In practice, it was one of the most layered projects I've run; not because any single piece was unmanageable, but because of how many pieces were moving at the same time and how much was riding on each one landing cleanly.

I led the program end-to-end over roughly four months, managing a cross-functional team of eight across project management, development, UX and visual design, content, and QA. On the client side, I was working with both their brand and marketing team and their technical stakeholders. Two groups with genuinely different priorities and different definitions of what success looked like.

The brand team cared about the experience; how it looked, how it felt, how well it reflected the Ole Henriksen identity. The technical stakeholders cared about stability, data integrity, and making sure nothing broke when we flipped the switch. Both were right. My job was to make sure neither perspective got lost in the process of trying to satisfy the other.

The Challenge

Platform migrations are never just technical projects. The code is the straightforward part; what makes them hard is everything that travels with it. Product data, content, customer records, historical orders, SEO equity; all of it has to move cleanly from one system to another without disrupting the live business or confusing the customers on the other side.

For Ole Henriksen, the data migration was the most complex piece of the program from day one. Their SFCC instance had years of product catalog data, content pages, and customer information that had been built up, modified, and in some cases patched together over time. It wasn't clean going in, which meant it wasn't going to be clean coming out without serious work to audit, map, and restructure it before a single record moved to Shopify Plus.

We were also running a full redesign in parallel; new UX, new visual direction and new content architecture. Which meant the development team was building against a moving creative target while simultaneously preparing for a data migration that had its own dependencies and timelines. Two complex workstreams, one team, one deadline.

That was the program as scoped. Then, about six weeks in, the scope changed.

The client came to us with a new request; and it was a big one. They wanted to build a skincare analysis feature: a tool that would use facial scanning technology through an external app integration to analyze a customer's skin and generate a fully personalized skincare routine with recommended Ole Henriksen products. The vision was compelling. It was also a significant technical and logistical undertaking that hadn't been part of any conversation during discovery.

The request came from the brand side. The technical stakeholders hadn't been looped in yet. And we were already six weeks into a four-month program with a data migration still in progress and a design phase that wasn't fully locked.

That's the moment where a lot of projects quietly start to go sideways.

The Approach

The first thing I did when the skincare analysis request came in was not say yes, and not say no. I said: let's understand what this actually requires before we make any decisions.

That sounds simple, but it's one of the most important calls a PM can make. A knee-jerk yes to a high-visibility client request protects the relationship in the short term and creates a much bigger problem six weeks later. A flat no without context damages trust and shuts down a conversation that might have a workable path forward. What the moment needed was a clear, structured discovery process; fast.

I pulled together a working session within 48 hours that included our development lead, the client's technical stakeholders, and the brand team. The goal wasn't to scope the feature on the spot, it was to get everyone in the same room with the same information so we could make a real decision together rather than having two separate conversations that led to two different expectations.

What came out of that session was clarity. The facial scanning component required integration with an external third-party application, which introduced a dependency we had no control over. The recommendation logic; mapping skin analysis outputs to specific products and routine sequences — needed to be built from scratch and tied directly into the product catalog, which was still mid-migration. And the UX to house all of it needed to be designed, reviewed, and built without derailing the redesign work already in progress.

The honest assessment was that building this feature to the standard it deserved, in a way that actually worked reliably and reflected well on the brand, was not a four-week addition to an existing program. It was its own workstream with its own discovery, its own timeline, and its own risk profile.

I presented that assessment to both stakeholder groups together, with a clear breakdown of what the feature would require, what it would impact in the current program, and three options for how to handle it. Option one: descope it from this project entirely and plan it as a dedicated phase two engagement that will launch shortly after the original project using a 3rd party support system. Option two: reduce the current program scope elsewhere to create capacity for a simplified version of the feature. Option three: extend the timeline to accommodate the feature without cutting anything else.

Giving stakeholders real options with real tradeoffs, rather than just flagging a problem, is how you keep a scope change from becoming a crisis. People can work with options. They struggle with dead ends.

The client chose option one. The skincare analysis tool was moved to a dedicated phase two, with a clear brief and a shared understanding of what it would take to build it properly. The current project stayed on its original scope with one adjustment: we built the content architecture and product data structure with the future feature in mind, so the groundwork was already in place when phase two kicked off.

With scope confirmed, I tightened the program structure. I introduced a weekly cross-functional sync specifically for the data migration workstream, separate from the broader project cadence, so the technical and brand teams had a dedicated space to surface blockers without everything flowing through one crowded status meeting. I built a migration readiness tracker that gave both stakeholder groups visibility into exactly where the data stood at any given point — what had been audited, what had been mapped, what was clean, and what still needed work.

For the redesign workstream, I worked with the design lead to lock creative decisions in phases rather than leaving everything open until the end. That gave the development team stable ground to build on and reduced the back-and-forth that tends to compound when creative and technical work are running simultaneously without clear handoff points.

What Happened

We delivered. The migration completed cleanly, the redesigned site launched on the agreed schedule, and the CMS back-end was built and documented so the Ole Henriksen team could manage their own platform from day one without needing to come back to us for every content update.

The skincare analysis feature — the one that arrived mid-program and could have derailed everything; became the foundation of a phase two conversation. Because we handled the scope change transparently and gave the client a clear path forward rather than trying to absorb it quietly, the relationship was stronger at the end of the program than it was at the start. They knew exactly what they were getting, why, and what came next.

The data migration, which was the most technically complex part of the program, came through without major incidents at launch. That didn't happen by accident — it happened because we invested time upfront in auditing and structuring the data before moving it, and because the weekly migration syncs kept small issues from quietly becoming launch-week emergencies.

What I'd Do Differently

I'd build a formal change request process into the SOW from day one; not as a bureaucratic hurdle, but as a shared agreement between both parties about how scope changes get evaluated and decided. On this project, when the skincare analysis request came in, we handled it well through judgment and quick action rather than through a process both sides had already agreed to.

A documented change management process does two things. It protects the project from scope creep that happens gradually and informally, one small addition at a time. And it protects the client relationship, because when a change request comes in, everyone already knows the drill; it gets assessed, options get presented, a decision gets made. There's no awkwardness around saying "that's outside scope" because the mechanism for handling it was agreed to before the work started.

I've built that into my SOW process on every program since.

The Takeaway

Scope changes don't have to be emergencies. What makes them feel like emergencies is when they get absorbed quietly, evaluated in isolation, or communicated to one stakeholder group but not another. A mid-project request, even a big one, can be managed without derailing the program if you slow down long enough to understand what it actually requires, bring the right people into the conversation together, and present options instead of problems.

The PM's job in that moment isn't to protect the timeline at all costs. It's to give the client what they need to make a good decision and then execute cleanly on whatever they decide.

Project Details Methodology: Hybrid · Team Size: 8 · Timeline: 4 months · Industry: Beauty & Skincare · Platforms: SFCC → Shopify Plus