When to use a hotfix on your site during a sprint (and when not to)

Every marketer knows about the allure of the “hotfix.” Something on the site needs to be changed, but the dev team can’t do it until the next release, which is two weeks away. Enter the hotfix option.

Originally, engineering reserved a hotfix for critical functionality. Not for making quick updates that are important to marketers. That’s changed as marketer demand for frequent updates has increased. Many marketers rely heavily on hotfixes to keep their site current. In fact, many point solutions are employed because they can aid marketers in making superficial changes on their site quickly, rather than employing engineering.

There are pros and cons to this approach. Hotfixes help marketers stay relevant, and for larger or older brands, it’s often the best way to keep up with speedy startup competitors. But, hotfixes are not always good for overall customer experience and can create chaos internally if things are done wrong. And perhaps most importantly for long term success, they decrease a marketers focus on a bigger strategy for built in agility and personalization on the website.

It’s best for marketers to run through this checklist before they make a new request:

When to use a hotfix: 

• Easy image or text changes for active promotions or to update content to be current 
• Updating things like stock levels, or shipping deadlines during holiday seasons 
• Using pre-QA templates within a personalization or content platform 

When not to: 

• Anything that involves the checkout transaction process 
• Anything that involves updated custom logic (such as Javascript)
• Anytime there is not a pre-built approved template available.  

Ensuring the changes are simple, needed, and safe is the key. If anything gets too close to important transactions, or is very complicated, things can go wrong – in real time. It’s best to create a broader strategy for more flexible site updates than constantly deal with the backlash from too many hotfixes.