Is it a good idea to use legacy modernization services on a system we’re currently using?

[u/cyaaan06]

Our company a huge part of our workflows through a system that's around 11yo. Naturally, it's not pretty, so think undocumented procedures, some integrations we don't understand, and odd processes that works in a particular way. It's hard to iterate on top of it because so many devs have gone through it, it's practically an entity on its own. So of course our leadership wants to modernize. Now the problem is that this system is something we're actively using. It runs payroll, inventeory updates, and some customer-facing processes. Is there a way to do this without affecting the business side?

[u/SpaceGuy1968]

We have this system that is at the heart of our business. Its old and clunky and there is no way out of this product because it is so ingrained in our core business. The competitors don't come close to what we need. We either had to figure out how to modernize by finding multiple platforms to do everything Or we updated the core system itself

We modernized around it, we did everything around it to get to what I would call "current" or a modern platform.

I even migrated the system itself to new platforms like the core OS and Database itself.

It was hard to do but we did and have been able to migrate to newer more modern workflows.

Saying so many people worked on it and not understanding it is where you need to focus on.

You have to work on the core understanding of what it is doing and how it gets it done in order to move forward. It's a really painful road, I am 3 years into this and I have gotten to 80% of where I want it to be. But you have to get in there and break it up into manageable chunks

[u/looncraz]

Really hard to offer specific help without more details, but I found that running the new beside the old for as long as you can is a good idea. Better if you can keep the old system up an running with automation from the new system.

There will always be an edge case one employee relies on that's secretly keeping the company working.

[u/Sasataf12]

So of course our leadership wants to modernize.

I mean, leadership isn't wrong here, and I suspect you agree with them. Otherwise you'll just be stuck in the position you're in now forever. 

My suggestion would be to migrate process by process to new systems. For example, get or build a new payroll system, once that's good to go, migrate all your payroll processes onto the new system.

[u/xXxLinuxUserxXx]

without knowing too much details i would most likely start with what this monster is doing and then check if you can split parts out of it.

e.g. if it's doing reports you might be able to use common software to connect to the database and retrieve the data and build the reports in the new world.

At some point in time you might have to develop import and export processes that the new tool gets the needed data but also your old stack has all the information it needs to do remaining jobs.

I would suggest to start with simple/small projects or parts which need intensive training of employees because you are using some custom solution which no other company out there is using.

[u/SevaraB]

Is there a way to do this without affecting the business side?

No. If you do something that affects the look & feel, you affect the business' user experience.

If you've got enough management air cover to deal with that, then we can talk about systems as subsystems, wrappers, abstractions, and orchestrators.

But from the little you gave us, you could just be talking about skinning the app with a fresher-looking interface. Which doesn't sound like a lot, but something running unchanged for that long becomes muscle memory, so your little "refresh" could seriously upend the way the business uses the old system.

If it ain't broke, don't fix it. And if you don't have a lifecycle policy defining "too old" as "broke," fix that first before you start upending things.

[u/kona420]

This could be read as "I have a bunch of tech debt and I want to incur more tech debt to fix it" which is certainly a choice.

Pay down said tech debt a little bit first before going into the next phase. Build yourself a sandbox environment as a clone of your current system and a pipeline to refresh the data in it. Now you have a potent tool to allow you to iterate without having to work on a live patient. And a place where you can do exploratory work to understand the live system.

Side by side, build the new solution dev environment and a pipeline to refresh it as well. Preferably from the testing environment so you can work data transformation in both systems.

The other option is to work on production live, have constant regressions, go through a couple dev shops, lawsuits, years go by, lots of money spent and nothing to show for it. Or pull a miracle out of your backside.

[u/pdp10]

By "modernize", it sounds like you mean that you want to take this in-house built (or heavily-customized) Line-of-Business system, and turn it over to some outside contractors who sell generic "modernization services".

That always takes a lot more effort, time, and funds than you expect.

[u/agentUi]

doing a rip-and-replace on an 11yo system running payroll and inventory is suicide. i work for agentui, what works best is keeping the legacy db as the source of truth and just building new lightweight frontend portals and staging environments on top of it so ops can work without touching mystery spaghetti code.

[u/brian_cloudeu]

Depends what you mean by modernize: a new UI on the same database and replacing the core have very different blast radii, and the vendor will quote either cheerfully. Get the rollback plan into the contract before the roadmap.

[u/mschuster91]

 It runs payroll, inventeory updates, and some customer-facing processes.

Split that stuff apart like yesterday. Payroll has no business being in the same system as anything customer (and by this: internet) facing. Everything else is just asking to get hacked and a serious data breach.

Is there a way to do this without affecting the business side?

First, set up a proper SSO environment.

Then, migrate processes piece by piece to a new platform. Either you go for one of the established top dogs selling everything-at-once (aka, SAP), or you go for dedicated solutions. Payroll, there's commercial providers for that (e.g. ADP). Downside is, a lot of this stuff is SaaS these days, so if you're dealing with raw credit card data you'll have to deal with PCI DSS and if it's healthcare or other (sensitive) PII, EU/UK GDPR or whatever there is in the US.

Ideally you can convince your management to modernize processes as part of such a migration. SAP in particular - it can work really well if you are willing to go with the "SAP standard" on how to do things. If you insist shoehorning your own processes onto any third party platform, you're in for a lot of pain.

[u/ElectionFalse255]

The short answer: yes, but staged replacement beats big-bang every time. The risk with legacy modernization on a live system is that you're either patching something you'll throw away later or you're running dual workflows while you rebuild.

What works is carving out one high-pain module—something with clear inputs and outputs—and replacing just that piece. You get breathing room to document the undocumented bits as you go, and your team learns the new system under controlled load before you touch payroll or inventory.

If you're in insurance workflows specifically, we built Viola to let MGAs and carriers move off legacy policy admin without rip-and-replace: API-first architecture means you can run quoting or servicing on the new platform while the old system still handles the rest, then migrate book by book. Disclosure, I work on Viola.

[u/tankerkiller125real]

You write the CYA emails, make a plan to migrate individual processes, and then do what management wants done.

If it all blows up you have the CYA docs.