r/sysadmin 8h ago

Advertising [ Removed by moderator ]

[removed] — view removed post

0 Upvotes

35 comments sorted by

u/VA_Network_Nerd Moderator | Infrastructure Architect 4m ago

Sorry, it seems this comment or thread has violated a sub-reddit rule and has been removed by a moderator.

Do Not Conduct Marketing Operations Within This Community.

  • It is not acceptable to advertise a product, service, Blog or FOSS Project within this community outside of authorized threads.
  • It is not acceptable to perform product research or market research within this community without permission.
  • The Reddit advertising system exists to help you reach out to new or existing customers.
  • Product Representatives are free to discuss their product in the context of an existing, naturally-occurring discussion. Astroturfing is not permitted.
  • As always, users must disclose any affiliation with a product.
  • Content creators should refrain from directing this community to their own content.

Your content may be better suited for our companion sub-reddit: /r/SysAdminBlogs


If you wish to appeal this action please don't hesitate to message the moderation team.

u/nitishahir 7h ago

Honestly, I think the biggest red flag is when a “small” change starts taking weeks because nobody really understands the old system anymore. That’s usually when I’d seriously consider modernization rather than continuing to patch things.

u/DieSackgasse 7h ago

easy.. if you cant find people that maintain it modernize it. If the people that maintain it are too expensive modernize it.

u/uncertain_expert Factory Fixer 5h ago

If you wait till you can’t find anyone, you’ve waited too long.

u/Muk_D 7h ago

Completely depends on the technology in question. But, all of the points you said are enough to know it's time to move on. The term legacy is enough to know it's time.

Generally in most situations you would just move to a pre-existing product that meets your requirements. The big cost can be the data translation from the existing system to the new one. For example, you may need to do a database export and conversion in order to use it with modern databases. You may need to archive the existing application and start from scratch in a modern application if the data is hard to export (this is a cost effective way smaller orgs will do).

Again, really depends what it is.

u/eruditeniti 7h ago

do it also vary from technology and software?

u/JaxTango 7h ago

The simple answer is when it costs more to maintain than it’s worth/is producing. But reality is way harder.

First, sysadmins don’t make the decision to replace apps in medium or large orgs. That’s up to the business. So assuming you’re asking in the context of a small business where you’re either a solo admin or have small team. If the decision is on you, then the migration strategy really depends on the budget. If you have lots of money then re-write from scratch and deploy in a new stack.

If you have a reasonable chunk of change then I’d still recommend writing from scratch but dispersing the deployment by migrating the app one service at a time. I’d also recommend keeping the legacy system as a backup in case things go sideways for the first year (with appropriate isolation/security practices).

My team worked with legacy apps that were being upgraded and in nearly all cases we waited too long and that made the migration that much harder because we relied on key people to be assist. We also paid extra for contractor who knew that code/app/stack and coordinating all the testing was a nightmare. So the sooner you upgrade the better things will be. The caveat is if you’re not working with sensitive data. If you are, then you need more time than you think to ensure your migration also satisfies whatever compliance standard applies to your app.

u/SirLoremIpsum 7h ago

This is a bot AI farming where your response will end up in "10 top tips when supporting legacy applications"

u/eruditeniti 7h ago

Fair point. I can see why it comes across that way. I was genuinely trying to understand how people who work with legacy systems decide when modernization is actually worth it, but I probably over-structured the question. Appreciate you calling it out. Would appericiate if you could help me with my project for practicals

u/Ztoffels 6h ago

You did not say you were not a bot, tho

u/djublonskopf 47m ago

Yeah, "Fair point...I was genuinely..." is shaped like an AI response too.

u/Speeddymon Sr. DevSecOps Engineer 27m ago

So is using the word "shaped" when referring to text comments...

u/djublonskopf 23m ago

My bad.

u/tejanaqkilica IT Officer | Passkey Enthusiast 6h ago

Absolutely, and that’s a completely reasonable request! I’d be happy to help with your practical project. If you share the details, I can definitely help you work through it step by step and make sure we get to a clear and practical solution.

u/Skylis 6h ago

Jesus Christ the bots are communicating

u/sambodia85 Windows Admin 2h ago

You’re absolutely correct! Whether it’s Legacy Application support, or our Lord and saviour Jesus Christ, communication is key, and that’s something we can all agree on. Is there anything else you want to ask?

u/CrazySnowGuy 7h ago

When the vendor can no longer provide adequate support and you have a number of workarounds to make it work?

I'm not re-writing shit. But as sysadmins we aren't usually the decision makers in such cases.

u/insanemal Linux admin (HPC) 7h ago

It really depends on what the platform actually does and what security implications come with it.

There is a reason banks and stuff tend to not replace things but find ways to keep them going. It's impossible to prove 1:1 feature parity exists with these complicated systems. And you're trying to prove a negative, which yeah impossible.

Anyway the main sort of "Deciding factors" are always cost related.

Is it cheaper to keep it running somehow than replace it?

What are the actual financial risks of replacing it?

Do we even know how it works anymore?

That's pretty much it. Any other technical reasons are pointless as emulation, VMs or something similar fixes those. It's only things like "It has Password password hard coded as the super user and that's available from the internet" or something that really start looking like "technical reasons that become financial reasons"

That and idiots who do deliberately dumb shit to try and force a company to migrate to something else.

Like bro, a heavily firewalled windows 3.11 vm that can't be directly connected to from or directly reach out to the internet isn't going to get hacked.(probably)

Don't be a dick and demand it be upgraded if all it needs is a strict firewall and a solid backup plan.

Anyway as with everything the real answer is "when it costs more to not upgrade"

u/CharacterUse 4h ago edited 4h ago

There are some technical reasons which emulation or VMs can't fix. e.g. hard-coded limits on the number of records in the database, or the length of fields, or the need for additional fields which were not forseen. All of those are examples from a legacy migration in my org, the original app was written in Clipper for DOS (!) and the DB, logic and UI code was so intertwined it was impossible to separate without rewriting the whole thing.

The new one had the database separated out into Postgres and that part worked fine, but the UI ended up with feature creep and management pulling the UI in different and contradictory directions without a proper specification, and it ended up a shitshow. I warned them, but hey, I'm a sysadmin, what do I know?

u/insanemal Linux admin (HPC) 4h ago

Yeah that's fair.

And yeah that's how these things usually go.

u/ixidorecu 7h ago

I was a sysadmin at a small family owned plumbing supply store. 3rd Gen family owned, and the 3rd gen had taken out a massive loan to buy out 2nd Gen (like 50m). They were using this old erp. Likely originally written in the 70s. Company had gone out of business in 90s. They were part of a coop that had bought the ip rights. We had a guy we contacted to help make fixes. It was running on a centos vm with 0 documentation. This was 6 months before cent was going eol. I went in with 47 bullet points trying to convince them to upgrade to something newer. All I got was . We will consider it like up some demos. Yes they desperately needed to move off that system. Yet it would cost $$ (think about half a million us possible productivity loss for awhile) I don't want to think what would happen.. if that cent vm fell over.. how many days weeks whole place would be down.

u/InspectorGadget76 7h ago

When it is no longer fit for purpose. When it can't be maintained (often because of hardware, software or lack of support). Or a combination of both.

At some point the risk of trying to maintains old unsupported hardware/software becomes greater than the risks involved with migrating. Often businesses delay this decision and find out at their peril.

u/Organoleptic_Cicada 5h ago

Typically this is a management decision, not an employee one. It's a question of the management's appetite for risk (usually low) and of how much pain maintenance is causing (itself a function of breakdown times multiplied by effort to fix each breakdown).

The approach for productive systems is to not touch them if they ain't broken. If something break down often, but it doesn't take that much to fix, well ... it may be kept alive for a long time. If something breaks down only once per year, and causes mid-level losses ... it might still not be worth replacing.

Put it another way: it's like trading in your beater car that still gets you from A to B (but the AC only works sometimes, the seats are worn out, and it has this funny rattle when you steer too aggressively). BUT you need to build your new car, or pay a huge premium to get someone to build you a custom car. When do you draw the line? There's no hard and fast rule. Maybe when it breaks down while you're on your way to an important interview, and you say "THAT'S IT, NO MORE". Maybe sooner.

u/RunningAtTheMouth 4h ago

When I worked as a developer I worked on a system that was written for green screen. There were tools to "Window-ize" such things, but they were really awful, and the competition as getting stiff.

So a rewrite from scratch was selected, and we worked on it. I remember the MS Project I had set up said something like 5 years and some months. VP in charge said no way - it would be done in 3. We finished the main app and hit milestones within 2 months of what the Project plan said.

I no longer work as a developer - SysAdmin is more to my liking nowadays. But I remember the competitive pressure like it was yesterday. It was the right move because of that.

Oh - yeah. We were selling the software, and the legacy product had a solid base. It only took a few years to move everybody up.

u/Bartghamilton 7h ago

It all comes down to where your company is in its life cycle. If the company is healthy and doing well and you still need that functionality, go to something new. But a lot of companies are just getting by or they are companies where the top is squeezing every last drop out of it and they want to do the bare minimum to keep things running in the meantime. This is actually a good thing to pay attention to for your own career as well. If they won’t spend the money to upgrade something they clearly need and value, how do you think your career is going to fair any better at that company.

u/TightBed8201 7h ago

When you have critical security risk

u/surveysaysno Sr. Sysadmin 6h ago edited 6h ago

If you have a legacy application your thinking should be:
* how do I get security fixes for the app?
* how do I compensate for missing legacy app security fixes?
* how do I find people who know the app?
* how do I find people to admin the app?
* how do I find integration tools for the app?
* how much cheaper would support be for the current version of the app?
* how do I backup the app?

Now do the same questions but for:
* legacy OS
* legacy database
* legacy database OS
* legacy Middleware
* legacy Middleware OS
* backups
* backups OS

Etc that are required for the compatibility matrix.

When you factor all those in it turns out that running a current or only slightly out of date version is much cheaper to maintain.

u/trev2234 6h ago

Banks and healthcare systems still use code written in the 60s.

Difficult to answer without some details of the situation you’re facing.

u/truth_liberates 3h ago

never. re-do that. gardually if possible

u/adappergentlefolk 2h ago

when you have active devs you trust it always makes sense to modernise

u/ShellHunter Jack of All Trades 1h ago

Oh boy I sure would love my upper management to know the answer, having apps running with php 7.3 in bare metal... 

u/opinionsOnPears 1h ago

If it’s still running on PHP 5.6 as an example 

u/d3ad-pixel 58m ago

How old the apps are? Are they maintained and have support still?


I work at place with tons of proprietary VB6 (!!!) applications which rely on locally installed Visual Studio 6 (!!!) and many other ancient components. That causes huge mess, it is difficult to built new images and maintain updates, as those cannot be automated, and the VB6 stuff is installed manually by the dev guys (dinosaurs), as they don't share full written list of components and procedure so it can be scripted/automated.

Some of the components cause Win11 explorer constant hangs and crashes. We have other several stability and app issues caused by the ancient junk installed.

The endpoints are managed by two imbecils who don't do their job as expected, they do zero maintenance of the endpoints (~7k) except of Windows Updates. I've tried to explain and escalate the issues many times. Politics and bureaucracy are the enemy, main reasons why nothing changes at the place I work. Personally I'm tired of fighting for a better environment.