insights! #118: Rethinking legacy: these 3 principles make your old system fit for tomorrow

Christoph Korfhage 

I hope everyone has already had a bite to eat and isn't too tired after the meal. Great that you're here. A nice small group today in our masterclass. You all know the topic. We're now going to take a look at how to love old systems and still make them sexy. A little opening question for the group: who has already seen a big re-platforming project run into a wall? Or not go the way you initially imagined. Everyone's promising, really, one or two of you. Yes, in the end probably almost everyone. Today we want to prove that there is another way, how to do successful further development without having to do a complete re-platforming. And specifically, that this also works on the basis of a system that has grown over 20 years. There are three of us here today. My name is Christoph. I'm Head of UX at Synergy, I'm from Düsseldorf, I've been doing this for over ten years and I'm here together with Jasmin. 

Jasmin Kahl 

Yes, Jasmin Kahl from Soennecken. Product Owner, or responsible for our shop systems. I've been at Soennecken for ten years and in IT for over 25 years, and I'm based in Cologne. Bene. 

Benedikt Grimm 

Hi, I'm Ben. Head of Frontend at Synergy. So we look at all the technical stuff. I'm from Mörs and I've been doing this for quite a while too. 

Christoph Korfhage 

We'll do a very quick introduction part, but it really won't take long and then we'll get straight to the point. About Synergy: we're a full-service digital agency, we come from Cologne, we also have an office in Dortmund and now in Berlin too. We're very strong in the whole B2B commerce space, we've been doing that for a few years now, and we're part of the Time to Act Group, which is also based in Cologne, has over 1500 employees and basically offers the entire range of IT services you can imagine. You'll certainly find the rest on the web if you google it. And with that I'll hand back over to Jasmin, who will say a few words about Soennecken. 

Jasmin Kahl 

With pleasure. Here you get a bit of an impression of what things look like at our site. Our main location is in Overath, near Cologne. Up north in Melsdorf we have another large warehouse location, and our development team is based in Essen. Right, here are a few numbers, data and facts. What's important about Soennecken is that we are – we're a cooperative for office supplies, so actually a different legal form for once, which also brings a very different, or let's say distinct, complexity to the things we deal with every day with our members. We have various services and products in our portfolio for our members, and today we're actually looking at the shop systems. We have two. On the one hand there's YoCommerce, an open B2X shop system, and today – today we're talking about „Your Procure“. There we're talking about closed shop systems for our members. 

Christoph Korfhage 

Exactly. Now we're getting straight to the point. It didn't even take five minutes. Perfect. The starting situation. Jasmin just said it, we're looking at „Procure“. The names are all very similar and tongue twisters are guaranteed. „SoProcure“ has been around for more than 20 years and has been continuously developed further. It's a procurement solution that Soennecken created for its members, and I think you can best tell us more about that. 

Jasmin Kahl 

Exactly. It's a closed shop system, very, very complex. I think, if I pull up the numbers, we have over 1500 functionalities and setup options that we hand to the specialist retailers and the shop administrators on the customer side within the system. And I think that shows a bit of what's inside in terms of functions on the topic of procurement. Because that's what we pass on to our members. What they get from us is a product with which they can map procurement processes with their own customers. That's the short version. I could go on for hours and tell you a lot, happy to do so afterwards, but otherwise I'll lose you here. 

Christoph Korfhage 

We already said it's been in use for over 20 years. That naturally has a small consequence, Jasmin, doesn't it? 

Jasmin Kahl 

Yes, it has a consequence. Don't be alarmed. That was state of the art 20 years ago. But what we do have is a very robust and high-performance system. That means it runs, it's stable. Our members can safely map their work processes and procurement processes with their customers every day and it runs smoothly. Now comes the „but“. The frontend, as you might guess, no longer meets the latest standard. In some cases you probably need glasses or you have to zoom, depending on which desktop you use on site. Accessibility. And what – you have these fragments. And what you can perhaps also see, over the whole 20 years, is that on the one hand you have things you no longer use in terms of functionality and that were never removed. That means you end up with fragments. And on the other hand, things kept being bolted on, and over those 20 years people didn't always stop to think: where does it actually make sense to build this in from a UX/UI point of view? Instead it was just placed somewhere underneath. And that's why today we have the Frankenstein. 

Benedikt Grimm 

And to all of us – all right, we need a glow up. We have to do something to let this platform, which is really great and brings an incredible number of features, shine as well. And how did we do that? First we looked at – we have a backend, that's basically the configuration screen, you can imagine it, and we have a SoProcure frontend. That's what you just saw. That's essentially what the end users operate. Now the situation is: in the backend we have a rather spec-style UX. That's maybe okay, because how often do you go in, change the setting – looks fine to us for now – and in the frontend, that's where the gap is that we have to fill. That's where the UX is outdated. We have to adjust things a bit and we have to make it so that members don't necessarily have to navigate through the manuals. And that's why it was also relatively quickly clear: we keep the backend and we only adapt the frontend. How do we do that? Basically similar to what you've heard in 500 other talks about composable commerce. 

Benedikt Grimm 

We say we simply leave our provider systems underneath in place and build – we added an API layer. And to that API layer we dock our new frontend. We built it with React. And that gives us the option to add flexible building blocks in the future. And not by building a completely new e-commerce system, but by rebuilding only the parts that are genuinely relevant to us. And the systems that give us all the power, we simply leave them in place and keep adding to them, maybe in the future with an AI tool or with a CMS system. And as a result we also have significantly lower risk, because all the business logic – and that's the most complex part, the thing that usually goes wrong in these projects – we don't have to rebuild it. And then of course we have to ask ourselves the question: can this actually work? So the typical pitch: we say we're going to do it this way. Sure, if you get the trust from the client, then you go in that direction, but of course we also want to be safe about it. That means we first do a hackathon – we did a hackathon, together with the colleagues from Soennecken, and locked ourselves away on site in Essen for two days. 

Benedikt Grimm 

It was three days, I think, actually. Three, exactly. We locked ourselves away for three days and tried the whole thing out, specifically in the form of doing one complete end-to-end run. We simply had everything generated from the product catalog through to checkout and a few functions in the account area, with a lot of help from Gen AI, and together – we tried it out with the colleagues, put flipcharts in every possible corner of the rooms to roughly stake out the features, and it works. After those three days we could really say that it works in the form we're planning here. That of course also clearly reduced the risk for Soennecken, who naturally also have a responsibility towards their members. Absolutely. And then comes the exciting part: the design process, because – just as we noted earlier, the features are very detailed and that's where, in my opinion, all the magic lies, Koffi. The devil is in the detail. And I'm curious to hear how you tell it. 

Christoph Korfhage 

– in the detail. Yes, exactly. So basically the goal is to transfer the existing functionalities one to one, only better, into the new world. But to do that you first have to find out what these existing functionalities actually are in detail, because 1500 setting options that can all be combined with one another – you can't really test or configure your way through that. You have to understand it systemically. We started by setting up a UX manifesto and defining a few ground rules: how do we want to approach the design? Which mechanisms do we use? Which patterns? We defined that all interfaces are responsive, even though 95% of users operate the tool on the desktop, simply because we don't know where the journey is heading. Maybe at some point people will want to do smaller things on the fly and on mobile. The use cases will probably develop a bit in that direction, and maybe it's simply the case right now that it's so hard to use that it never occurred to anyone to open it on their phone. We defined that the new solution should be accessible, even though we're not directly affected by the BFSG – but there too, the fewer barriers something has, the more users can use it, and the more future-proof we are as well. 

Christoph Korfhage 

That's why we included it directly as a requirement, and then we defined modular processes, recurring UX patterns, popover menus, scrape modals, all these UX/UI technical terms, and then also set up a master table with a great many functionalities, because tables play a very, very important role for this interface. The new frontend is then built on a white-label design system for which we already have a storefront in use that brings many patterns with it. And then, at the beginning, we created a completely new page frame. That was basically the, let's say, preparation for the actual project. Creating the page frame, adapting all the patterns to the basic conditions we found, an account navigation, all tables optimized and made accessible. But that wasn't the main challenge in this project. I mentioned it earlier: a lot has happened in 20 years, sometimes a bit of uncontrolled growth. And then of course you have to look at it: what can go? What is definitely still needed? How do we validate that? There are an incredible number of features that can be switched on or off by the customer admins and combined with one another. There is a manual, that's our bible, but it doesn't always define everything down to the last detail and isn't always fully up to date. 

Christoph Korfhage 

To illustrate the complexity a little, we brought along an example, a before-and-after example. This here is the current world. We're now diving into the specifics of a typical procurement process, namely the configuration of assortment roles. The use case is: I have multi-level purchasing processes. Chief buyers, sub-buyers, sub-sub-buyers who have to set up various approval rules, define roles, which assortments they can actually access, which products they can buy – because with SoProcure you can plug in an enormous number of catalogs from other manufacturers as well. That means we can't control the assortment ourselves at all. That mostly happens via this configuration of the roles. Let me show you a bit how that goes. We go via the navigation. Then we go into administration, into assortments, into assortment roles. There we see the roles in the overview. A table, let's go into the admin role and then at the top we see we can make a few basic settings for this role, and underneath that – that's where a bit of the magic happens, the assigned segments, that is: which assortments, which segments can I order from? And there we want to configure the office supplies segment. What just happened? 

Christoph Korfhage 

Reload. Where do I configure that now? I have to know that I need to scroll down a bit further. That's where the configuration happens. There I can make settings. I can do super impressive things. A first-level approval procedure, for example. Purchase order of €500. Total value: should an approval process be triggered? Second approval procedure: if an item worth more than €200 is in the cart, an approval also has to be set. And I can set various other dependent checkboxes there. You can see the table reloads every time, more and more checkboxes keep appearing. All this logic sat purely in the frontend. That means it wasn't really documented and it all had to be worked out now, first finding out where which dependencies lie. And then I mustn't forget to click this save button down here on the right, because if I don't find it, everything's gone. Now I've configured the segment, and if I now want to configure a second segment, I'd click on the individual segment again and then this area opens up below again. When we saw that for the first time, we thought: „Yes, cool function. How do we deal with this?“ This really isn't bashing. The functions are great and they're super valuable and they're really well used, too. 

Christoph Korfhage 

It's just that I think we'd find it hard to sell it to new people and new customers who come on board the way it is right now. We simply have to do something. You almost need a degree for it. Yes, exactly. And that's why the glow up. We first rated the feature as complex. That was the initial classification. That means: complex feature, we need some kind of workflow for it to really master it. What did we do? We created the deep dive grooming format, where we coordinate very closely and intensively, in particular the PO and the subject matter expert together with technical counterparts and then UX and UI. Then we lock ourselves away for half a day and dissect the feature completely, defining what the existing functionalities actually are, where the delta to the documentation might be, where you can really cut something out if at all possible. And that is then, so to speak, the basis, and then in a second step we go through: we see room for improvement, whether we – how do we envisage the whole thing? We did a scribble together in that meeting as well, and that was then attached as a PBI with a very short description, basically. 

Christoph Korfhage 

And that was then the starting point for our UX/UI rework. Now fast forward. What does the feature actually look like in the future? This is the after example. The same functionalities, the same functions. We can already see the much cleaner page frame, which simply contains far less information. We have a dynamic account navigation. Depending on which rights and roles I have myself, this navigation gets bigger or smaller, depending on how many features I can actually use. We enriched the first table of assortment roles with active segments and last changes. Why? If I haven't configured a segment, the role isn't really there, it isn't really capable. I have to know that somehow so I can see where my misconfigurations are. And the second thing: something has gone wrong. Yes, okay, then I sort by last change, because then I also know that most of the relevant things are sorted straight to the top and I can get in quickly. And then I click on „Play“ here. I hope I can keep up. This is now – we recorded this in advance, of course. I'll now go into an assortment role again and navigate one level deeper. For that we also created popover menus, because there are still a lot of functionalities hidden that previously were all connected somewhere in the interface. 

Christoph Korfhage 

Now we're in the assortment role, in the general settings. We split that up as well. There are two tabs here, general and segment configuration. That's where the magic actually happens. Now we have our new, tidied-up table of the individual segments. That one was enriched as well, namely with the catalogs, the approval procedures and the notifications. None of that existed before. Before it was simply a plain list. But this way I can already see: what have I actually configured on my segments in principle? How many catalogs are in there? How many approval procedures are active? Do I have any notifications here? Am I missing them or are they bothering me? And I can switch them off quickly because I know where they're hiding. And little details like that – you can call them little details – are included as well. Classic – the classic little details: if you currently deactivate a segment, that segment is deleted. So all the settings that were in there before are lost. Users have got used to that by now, they generally know it, but we took it as an opportunity to add a few validations there as well. Are you sure? Are you aware of the consequences? – so that we also reduce user frustration, especially for new users, because you simply don't see it. 

Christoph Korfhage 

We did that even though it wasn't specifically required in that area, because users have got used to it. And we also did it because the alternative would have been to rewrite all the logic in the backend, and we wanted to avoid that. That's the quick fix. We don't have to change anything major. It can be solved really quickly. User frustration is reduced. Simple solution. With that we move on. The second thing you can see now: all these settings that used to be below the table – we simply pulled them out and laid them over the table. That way the table is still visible. I've encapsulated all the setting details and, again, introduced a substructure here so that it's a bit clearer and easier to manage. Here I can now make exactly the same settings that you just saw in the current-state example. I can select „catalogs“ and add them to the segment. I can go into the approval process and set the same complex approval procedures I could set before. And we then also introduced the notification functions. You can see that at the top right. Before, they were hidden somewhere in between. You had these little notification items all over the place. We clustered that, because when I set a notification now, you see the green button bubble at the top left, which already says: okay, something has become active, and we then play exactly these settings back onto the table once I've saved my level here. 

Christoph Korfhage 

„Save“ is a good point too. Much clearer, much more concise. I can make my entire configuration much faster. First key takeaway. UX design is important and plays a big role in significantly improving the user experience, of course. Many of the reworks now seem obvious in hindsight and totally self-evident, because sure, why wasn't it always done that way. The path to get there is a bit harder, because you simply have to invest a great deal in communication, in coordination. We created these deep dive grooming sessions. We defined fixed dev handover slots in our sprint format, 90 minutes per week that always take place, because we also use them to clarify all the follow-up questions internally, to show the devs interim results, because they aren't part of every coordination meeting, so that they can raise a veto early and still influence the design. And in general we also involve focus groups, groups from Soennecken who look at features early on, so that we get buy-in there as well. And with that we move on to the development process. 

Benedikt Grimm 

Because everything that Mr. Koffi designed so nicely here of course also has to be developed by someone in the end. And for that we naturally make use of a modern tool. Can you click one further, Koffi? I'm just being Mister Obvious. We're also including AI in the development workflow. And we do that deliberately. We don't do it – we don't just have it all generated in one go, hoping the perfect one-shot result comes out. We say we proceed iteratively. We do it by using MCPs, Model Context Protocol, which you may have heard about somewhere else. USB-C plug for AI, it's often called. We simply hand it a few new tools. In our case, we have a tool for generating code from Figma designs and, in doing so, bringing the design tokens that Koffi and his team meticulously prepared in the design system over into our codebase. In doing so, the agent follows the structural specifications we give it. We provide a whole set of rules and guidelines so that it's built the way we want. But the important thing about it is that we only let the AI do the shell construction. 

Benedikt Grimm 

When we say, build the table that Koffi just showed, for example, or the slide-out panel, the colleagues from the technical side then take over and implement the whole thing in detail. We use Tailwind, we use React. That's quite practical because AI works pretty well with those. The most important thing is the fine-tuning. The colleagues do that by hand. It's important to know that, in parallel, all the interfaces of course have to be built as well. We saw earlier that we have our backend provider system. Out of the box, that doesn't have the interfaces yet. That means the backend colleagues on the Soennecken side of course also have to build the whole thing, and they need the requirements from us. But that can happen in parallel, because it's already quite clear what the end result is. We already know what the function will be in the end and which features there should be, especially after Christoph and Jasmin have worked it out in their groomings. And what's becoming more and more important – and this will probably come up more and more for you in the future too, when we work with AI, above all in the code area – is that we of course also have to check the whole thing far, far more strictly. 

Benedikt Grimm 

With SonarQube we have a pretty good set of rules in place, allowing us to check quality in an automated way, because we're in an enterprise environment here. If there's a bug in there, then … A catastrophe? It's a catastrophe, because – really, I don't even know how many customers are out there, roughly? Customers? Oh, that's a very high number. That really pins it down. 

Jasmin Kahl 

I think it's six figures. And we, or rather our specialist retailers, can't afford to lose a single day, not even half a day. That comes with a really high loss of revenue, and the customers on our specialist retailers' side aren't really happy either. That's critical. 

Benedikt Grimm 

That's why: strict test protocols within the team. We do unit tests and so on. Everything you know from a typical project, we do too, of course. Just a notch stricter, simply because we know we're having part of it generated by AI, and we make the review process significantly stronger. The important key takeaway at this point is really that applying this innovation and these new models takes trust. We couldn't do it, and couldn't do it very successfully in this project, if we didn't have the stakeholder trust from the Soennecken side. We have to be able to rethink solutions completely, even spontaneously. But at the same time we also have to be able to limit the risk. That's why I can only recommend hackathons like this. It has worked brilliantly every time we've done it so far. Give trust – I think you'll be rewarded. 

Christoph Korfhage 

Exactly. And if we weren't working in such an agile approach and had defined a fixed price up front with all the requirements written out in detail – first of all, that would hardly be possible. „That doesn't really work, because it's so complex“ – then we couldn't run the project this way at all. It only works if we work agile and in a very collaborative mode. Exactly. And then we come to the project. Right. 

Jasmin Kahl 

So for anyone now expecting us to have a project plan with everything written out and declined in detail, what we do and when – with time windows in it – we have none of that. We sit down and we know which modules and functionalities we all have to build. We also treat ourselves to some on-site time where we sit down together and then actually write rough estimates against the individual topics. And that puts us in a position to do phase planning. And that also works well upwards into management, staying able to discuss things on the basis of this phase planning or staying in the discussion: when can we deliver which things and when are we likely to be finished? Now you might expect that we took the Scrum Guide and follow it meticulously and stoically and always go by the book. No. If you imagine it, the team is actually made up of, let's say, three sub-teams, or four if you're being honest. We have QA, we have the backend and the content team. And if all of us sat in refinement three or four hours every single week and discussed all possible requirements and got into discussion, half of them would probably be bored and have nothing to say, and vice versa, and we'd lose time – and we don't want to lose that. 

Jasmin Kahl 

That means we've set ourselves up very flexibly. We started as one team in the ceremonies and after every retro we look at what the pain points actually were. What can we do better? And then we're very flexible. Often it's a chat message. Two or three people talk it over, maybe get a nod from the next team, and if everyone gives a thumbs up, it goes into the chat and then it has immediately grown – a new process structure. That led to us separating the teams after, I think, three, four, maybe five sprints. That means the content team works with the UX team and the backend team with QA. We split the refinements, because the frontend team is often faster in implementation and development than the backend team. Exactly, and that's how we keep the lanes and can orchestrate the lanes quite well in the whole race. That actually runs entirely – that's already going very well. Right, and what are our learnings as well? We've found that, since we sit at different locations, different teams, it's very valuable to lock ourselves away together for a day or two. We do that regularly. 

Jasmin Kahl 

We also go out for lunch together. We have fun as well. We're not just at it the whole time saying: „Yes, okay, keep going, keep going.“ And the nice and special thing is, and I'm saying this now simply on behalf of the whole team: there isn't this client-service-provider barrier. At least I don't perceive it. 

Christoph Korfhage 

Neither do we. 

Jasmin Kahl 

There's no separation or „I can't say that now, I'll tell you afterwards“. It's really great teamwork and I think that's also why we can perform so well together. 

Christoph Korfhage 

Actually a really nice conclusion already. We did bring a closing conclusion with us, and this is it: dare to leave old things in place. Because the old isn't bad. Many tech partner agencies – we do it often too – say: „Okay, let's do a complete re-platforming, a fresh start, and off we go.“ But you can't manage that within a short project runtime. That's obvious too, of course, because all the complexity in the backend, which sits in the backend system, first has to be captured, then reframed, then rebuilt. That makes for a long project runtime. With this approach we've chosen here – more an evolution than a revolution – the whole thing is far more feasible and can be implemented in a shorter time frame, and with a genuinely customer-centric mindset at that. Because that's what the end customers ultimately care about. They aren't interested in how the backend systems solve it behind the scenes. What they touch has to be good, has to be understandable, and that's why this is such a quintessence of this project for us. We don't rebuild it completely; instead we reframe what we already had in the interface before. 

Christoph Korfhage 

Look after your legacy software, cherish it, but when you then want to add big new features, do it in a small composable building block alongside it, because that also enables the decoupling of backend and frontend. You don't have to set up a completely pure MACH infrastructure. You already get all the big advantages through decoupling, and you're then also flexible enough to add new building blocks quickly and become agile. Half an hour is always a short masterclass. And we're already through. We'd like to say another huge thank you to our team. There's no Team Soennecken here, no Team Synergy. It's simply one big holistic team. It's great fun working with everyone. And now we're ready for your questions. If you have any – feel free to scan the QR code, then you'll follow us on LinkedIn and there we'll also share the slide deck again. Yes. 

Jasmin Kahl 

So we started at the beginning of the year. I think we started in February. Exactly. February was when the first sprints began, the first groomings. We're right in the middle of it and the home straight is Q1 26. But we're actually right on schedule at the moment. We currently have no delay. If you look at the whole thing a bit, it's this bell principle. You have a very steep, long path that climbs up, and once you've reached the peak at the top – and that's where we are right now, we looked at it again last week with all the teams, we're right at the top of the bell – and now the tipping point is slowly coming, where things pick up speed. 

Benedikt Grimm 

Mind you, Q1 as feature complete. We've of course set interim milestones so that the specialist retailers can also look at it in the focus group, so that we get a feedback pattern as early as possible. And so there are these interim milestones. 

Jasmin Kahl 

Exactly. We'd now be mid to late Q3, with the specialist retailers on board, testing it comprehensively. And it's also planned that they can already go into the switchover with their first customers who have few modules in use or activated. How many are you on your side? 

Christoph Korfhage 

So two people in UX and UI, then, I think, two or three frontend – „2.5“, right? „2.5“, sure. 

Benedikt Grimm 

„2.5“. 

Christoph Korfhage 

„2.5“, right? „2.5“, yes exactly. And that was it, I think, from the Synergy part. 

Jasmin Kahl 

Exactly, on the „Synergy“ and „backend“ side we have two senior backend colleagues, two junior colleagues in training and two colleagues in QA. Exactly. And that's it. In relation to … Yes, exactly. Any further questions? Right. The backend is written on cplace plus. 

Benedikt Grimm 

That's already extremely performance-optimized. That means the underlying system already responds super fast, and that's why it isn't really our pain point. Exactly. Right, that happens in the … I think they write it in C sharp. I'm not that deep into it, but it performs really well too. I was surprised myself, but the colleagues know what they're doing. They already do. That's done in advance. Not in advance – that happens during development. That's what we have the QA colleagues for, who actually look at the load as well. But you look at it too, don't you? Exactly that. And for the actual backend system there are regular audits, because Soennecken also has to comply with certain certifications, I don't even know, 27001 and so on. Right, all the ISO certifications. There are regular audits for that, both in terms of security and in terms of load. Right, and it's all covered by monitoring as well. That means the infrastructure is monitored and then the red lights and the yellow ones go on somewhere if anything supposedly comes up. 

Christoph Korfhage 

Very good. Then we're through. Many, many thanks for taking part and for your attention.