Changing a business-critical platform without breaking anything

Situation

A global image-licensing company already had an embed programme used to put its imagery onto publisher websites.

We had an opportunity for SmartFrame to take over the delivery behind those existing embeds.

The scale of the opportunity was obvious.

So was the risk.

The embeds were already out there on websites we didn't control. Asking every publisher to integrate something new would have made the migration slow and uncertain.

There was another option.

The partner could keep the existing JavaScript entrypoint and redirect it to us. Existing publisher integrations would continue to work, while SmartFrame took over what happened behind them.

Much better commercially.

Also a fairly good way of breaking a lot of websites at once if we got it wrong.

What I did

I designed and agreed the technical approach with the partner and stayed directly involved in the implementation discussions.

The basic idea was to use their existing embed entrypoint as a bridge into SmartFrame.

That meant we could change the system centrally.

It also meant rollback had to be designed properly from the beginning.

We preserved the original behaviour and built a failsafe so the SmartFrame path could be switched off without publishers having to change anything.

The project moved through their lower environments and then into their candidate environment.

Their principal engineers and InfoSec team were involved in validation.

There was quite a lot of detailed work around redirect behaviour, allow-listing, API responses, assets and the behaviour of the embed itself.

Even tiny details mattered.

At one point I called out the difference between doing a redirect directly at HTTP level and doing it via JavaScript. Both could work, but the latter meant loading and executing an extra script in the browser.

That wasn't some huge architectural discovery. It was exactly the kind of detail that needed to be understood before putting the change into production.

We also had to preserve layout behaviour.

If our embed changed dimensions or responsiveness on a publisher page, technically rendering the right image wouldn't have been enough.

On the processing side, we prepared assets ahead of launch where possible and retained on-demand conversion for things that weren't already generated.

We load-tested the path as well.

The work involved engineers and QA on our side and multiple technical teams at the partner. My role was the overall architecture, the partner-facing technical agreement and making sure the migration had a safe failure mode.

Eventually the partner confirmed the SmartFrame layer was working in their candidate environment and we moved through to enabling the bridge.

Outcome

The SmartFrame path could be activated without asking every existing publisher to change its integration.

That was the important part.

We got the commercial advantage of a central migration without making the central switch irreversible.

I haven't found enough evidence to claim there were literally zero production issues, so I won't.

What I can support is that the solution went through staged validation, involved the partner's engineering and security teams, reached their candidate environment successfully and was subsequently activated.

And if we had hit a serious problem, we had a straightforward way to get back to the previous behaviour.

What I took from it

The rollback plan for a serious migration should exist in the architecture.

If undoing the change requires another emergency engineering project, you don't really have a rollback plan.

For anything touching a lot of customers or revenue at once, I want to know two things before launch:

How confident are we that this works?

And what happens if we're wrong?

The second question is usually where most of the useful risk reduction happens.