I'm dealing with a bit of a conundrum at work. We have a couple of extremely outdated applications written in VB5 that only get updated once or twice a year. To make any updates, we have to use a Windows XP VM with VB 6.0 installed, fire it up, make our changes, and then I run a script to transfer the updated code to our lab environment. However, IT is insisting that this VM must be retired due to security concerns, and the head of development isn't willing to allocate resources to recode these applications. Even though they do bring in some revenue, they aren't profitable enough to justify a complete rewrite. I've been looking for alternatives but so far, nothing seems promising since VB 6.0 is the last version that supports VB5, and I can only find Windows 7 as a potential workaround. What can I realistically do at this point?
5 Answers
It’s frustrating, but there are ways to keep these older systems functional. One option is to set up a dedicated lab environment for devs to work on. This could be either a physical server without any network access or a virtual machine in a heavily restricted area. This way, you can manage the legacy systems while also addressing the security concerns, though it may take some resources and negotiations to set this up.
Exactly! But whoever is in charge has to be pushed to either fund this or figure something else out.
In this case, a rewrite might be the best long-term solution. However, given the head of development's stance, it might be worth escalating the issue to higher management to emphasize the financial impact of maintaining that revenue-generating code.
Yep. A rewrite isn't even an option if the dev head's not on board—definitely need to push this up the ladder.
You bring up some solid points about risk management. Windows XP and VB 6 are both outdated and vulnerable. You might want to assess the actual risk of exploitation versus the reality of the system being mostly offline. Document your findings and have your management sign off on the risks. Keeping that VM off the network or using isolated tools for transfers could be a possible workaround.
I hear you. If it’s rarely online and not handling sensitive info, there could be ways to mitigate that risk and appease IT.
That’s true! Isolating the VM while documenting everything might give them enough comfort to let things be for now.
It sounds more like a management issue than a technical one. Have IT and development leadership discuss this openly to reach a compromise. You’re in a tough spot with the old systems, but only they can decide how best to address the security risks involved.
I agree! Someone from above needs to weigh in on the discussion to really address the risks and required updates.
I've faced a similar issue. At my old job, management was indifferent until we got a new director who really pushed for updates. Sometimes it takes a shake-up to get things moving!
It’s classic legacy code management. Security wants the old system gone, and they should clearly outline the risks to management. It’s about making a stronger case regarding just how risky it is to keep running unsupported software.
That could be a way forward if the budget allows. Sometimes even in larger organizations, these challenges can be tackled with creative solutions!