What we learned from our last webshop go-live

When you have worked so long and hard on a project, the most exciting phase for me is the go-live.

Especially with such critical changes as the release of a new web store, it is extremely important that everything works and interlocks. The losses for the customer if no orders can be placed after the go-live are enormous.

That's why it was particularly important for us to be optimally prepared for the release.

3 days before release

A web store cannot function on its own; it is always dependent on interfaces and other services.

Of course, the core of the webshop is particularly important: the products. But if products are to be transferred from middleware to a store, difficulties can arise:

Sometimes a field is not transferred or not processed correctly, then you notice that some data doesn't quite fit, and the data structure has to be adjusted again. Such things are not really major problems, but they can be very protracted due to communication via tickets or chats

In order to handle such problems better, we decided to spend the last three days before the go-live on site at the customer's premises. And that was the right decision. No matter what question arose or what decision we needed to make - there was always someone on site who was able to help us quickly. This on-site focus was very beneficial for the last sprint. We were able to implement all the points we had planned for before the go-live within these three days.

Our learning:
A joint final sprint before the go-live can make the project even more rounded and help to create short communication channels.

7 hours before release

The last three days before the release were therefore very successful and productive. The customer was sure: “We can go online like this for now.” But we found it difficult to find the point at which we were really fully satisfied.

We kept finding small areas that could be optimized, or thought about features that were planned for after the release: “This feature is not that complex, we can implement it before the release.” We could certainly have continued to optimize and improve forever.

But when the day of the go-live arrived and we knew: “It should go online tonight”, we had to slow ourselves down. There is no point in continuing to optimize endlessly if the customer was satisfied with the status quo as it was. After the release, there was still time to implement the remaining non-critical issues.

Our learning:
A go-live does not mean that the product is finished. But it is good enough to go online. This is because the go-live gives the customer the advantage of already having the new technical basis, especially in the case of a migration. And after the go-live, the next features can be worked on in peace.

1 hour before release

Then the time had come. We sat in front of our laptops at 9 pm and were ready. The last small bugs were fixed, the deployment went through and everything looked good on the staging server. Now we could go online.

But you still always have a little uneasy feeling: what if you've missed something? Something that was never noticed on staging and only leads to errors on the production side? What if, in the worst case scenario, no customer is able to order something or the payment doesn't work?

So we all sat anxiously in the team call and made the final preparations and settings.

When the webshop was finally online and the first orders started to roll in, we all felt a huge weight lift off our shoulders.

Looking back, you always know that you thought too much. But this worry probably also makes you even more cautious, attentive and careful.

1 month after the release

One month later, we can be satisfied with what we have achieved. There were hardly any problems and we were able to bring even more improvements and features online in the weeks following the release. Now the store is running even smoother and we are already working hard on the next functions.

In conclusion, we can be very proud of ourselves that we managed the release so well.