#legacy systems

for anyone in IT who's never actually audited what .vbs scripts are quietly running in the background.

microsoft's phasing VBScript out of windows. announced back in 2023, default-off switch expected around 2026-2027, full removal sometime after. the businesses that get caught off guard are the ones who never bothered checking what's still running on it.

7 signs worth checking for:

nobody currently on staff wrote it → dev left 3 jobs ago, zero comments, filename like final_v2_USE_THIS.vbs

it depends on a windows feature already being phased out → this isn't a someday problem, microsoft's holding the calendar

nobody would notice if it silently failed → no logging, no alerts, first sign of trouble is a process that just stops happening

the systems it touches have changed since it was written → hardcoded paths, credentials, server names sitting like landmines

it runs from one machine tied to one login → gets swapped during a hardware refresh and the automation just stops, no redundancy

security can't tell you what it actually does → long history as an attack vector, that's part of why it's being retired

you've already had a near miss and treated it as a one-off → that wasn't a fluke, it was a warning

what to actually do: start with an inventory (most companies have no idea how many .vbs scripts exist until they look), rank by what breaks if it fails (not by how old the code looks), tackle highest-risk first, usually rebuilding in powershell.

for anyone with a 2009-era desktop app quietly running payroll or inventory that nobody wants to touch.

the fix isn't ripping it all out on day one. it's figuring out what's actually broken vs what still works, and building a bridge between the two.

step one: an honest audit, not a rewrite. map what the app does today, not what the original spec said. list every dependency, including that barcode scanner SDK someone installed in 2014 and never documented. legacy apps fail during modernization more from forgotten hardware integrations than bad code.

three paths, pick deliberately:

rewrite → for genuinely unmaintainable codebases, slowest and riskiest option

refactor → keep the working core, modernize what's underneath (.NET Framework → .NET Core piece by piece), cheaper and breaks less

wrap → add a modern API/interface layer on top, legacy core keeps doing its thing, buys time without touching risky code

most successful projects mix all three across different modules.

keep the business running during transition: run old and new side by side, compare outputs daily, roll out department by department instead of all at once.

desktop-specific gotcha: hardware, not browsers. old label printers, signature pads, scanners often break on newer OS drivers. test every physical device early.

realistic timeline: 4-9 months for a mid-size app, and budget extra time for staff retraining and updating docs nobody's opened in years.

for anyone still running a Classic ASP app because nobody wants to touch it.

quick reality check on AI-assisted migration this year.

.NET 10 shipped as long-term support (patched through Nov 2028), and Microsoft folded its free Upgrade Assistant into GitHub Copilot's app modernization tooling. that part's genuinely useful for standard .NET Framework to .NET 10 upgrades, scans dependencies, flags deprecated APIs, hands you a migration plan.

but Classic ASP isn't .NET. no project file for Copilot to scan, no NuGet packages to bump. just inline VBScript calling COM objects that might not be documented anywhere at this point.

ask AI to translate a VBScript loop into C# and you'll get maybe 80% there. it won't catch the part where that loop is quietly working around a bug in an old database driver. somebody has to notice that by hand.

realistic path: full inventory first, strangler approach over big-bang rewrite, let AI draft the skeleton and tests, keep a human reviewing every business rule that carries over (pricing, tax, permissions especially).

full breakdown here:

At 137Foundry, we recently wrapped a legacy modernization engagement for a client whose core operations system had been running, largely unchanged in its fundamentals, for fifteen years. It worked. It was also nearly impossible to hire for, since it ran on a stack most engineers under thirty-five had never touched, and every year that passed made the pool of people who understood it smaller.

Here's what almost slipped through, and what we did differently to catch it.

The rule nobody remembered writing

About three weeks into the audit phase, we found a conditional buried in a pricing calculation that applied a specific adjustment for orders shipped to one particular region. Nobody on the current team knew why. The commit that introduced it was over a decade old, with a message that just said "fix pricing bug." No ticket reference, no further explanation.

We eventually tracked down a former employee, now retired, through a mutual connection, who remembered the actual story: a regulatory requirement specific to that region that existed for about two years and was then repealed, but the code that implemented it was never removed because nobody wanted to touch pricing logic without being completely sure it was safe to change.

If we'd migrated without finding this, one of two things would have happened. Either we'd have carried forward a rule that no longer applied to any current regulation, silently overcharging or undercharging customers in that region for no legitimate reason, or we'd have dropped it during a code cleanup and, if the regulation had somehow still been relevant in some edge case we didn't know about, created a compliance gap nobody would have noticed until an audit.

Photo by Tima Miroshnichenko on Pexels

Why we built time for this into the project plan explicitly

This is the part of a legacy migration that's easiest to underbudget, because interviewing people and reading old commit history doesn't look like "real" engineering progress to a client watching a project timeline. We've learned to make the audit phase an explicit, separately budgeted line item rather than folding it into general "planning," specifically because that's the phase that gets compressed first under deadline pressure, and it's the phase where the actual risk lives.

What surprised us most

We expected to find undocumented business logic. We didn't expect how much of it was actively still relevant versus how much was genuinely dead weight left over from rules that no longer applied to the business at all. Roughly a third of what we catalogued during the audit turned out to be safe to simply not carry forward, once we confirmed with the client that the underlying business condition no longer existed. That's not a bad outcome. A migration is a legitimate opportunity to deliberately retire dead logic instead of blindly reproducing everything, as long as the decision to drop something is made consciously rather than by accident.

The part the client's leadership didn't expect

Going into the engagement, the client's leadership expected the risky part of the project to be the technical rewrite itself, the part their engineering team was most nervous about. By the end, everyone involved agreed the actual risk had been in the parts that didn't look technical at all: finding the retired employee, confirming which of the thirty-some undocumented quirks we catalogued were still relevant, and deciding, with the client's business stakeholders rather than unilaterally, which pieces of dead logic were genuinely safe to leave behind.

That's a useful thing to set expectations around at the start of any similar project. The engineering work is usually the predictable part. The knowledge-recovery work is where the actual surprises live, and building schedule slack around it rather than around the coding phase tends to produce a much smoother project overall.

Where this fits into how we work

We treat legacy retirement as a knowledge-extraction project first and a technical migration second, because the technical part is genuinely the easier half once you actually know what you're building toward. The full framework we use for this kind of work covers the audit process, the prioritization, and the parallel-run verification period we run before any legacy system actually gets decommissioned.

Further reading

Wikipedia's entry on legacy systems if you want the general background on why these systems accumulate this kind of undocumented complexity in the first place.

Wikipedia's entry on tacit knowledge covers the concept underlying most of what a good audit is trying to recover, knowledge that exists in people's heads and was never written down.

The National Archives has genuinely useful guidance on institutional memory capture, written for government records but applicable to any organization sitting on decades of undocumented decisions.

If your team is looking at a similarly long-lived system and dreading the migration, the technical rewrite usually isn't the scary part. Finding out what the old system actually knew, before it's gone for good, is.

One more thing we'd tell a team starting this today

If we could give one piece of advice to a team about to start a similar project, it would be this: don't wait until the audit surfaces a mystery to start treating former employees as a resource. Build the habit of maintaining some kind of contact, even a light one, with people who've left after long tenures on business-critical systems. The twenty-minute call that solved our pricing mystery only happened because someone on the client's team still had a personal connection to that former employee. A team without that connection would have had a genuinely unsolvable gap in the historical record instead of a phone call away from an answer.

It's a small thing to build into a company's normal offboarding process: a brief, friendly note that it's fine to reach out if a question ever comes up about a system someone used to own. Most departing employees would rather answer one good question years later than watch, from a distance, as something they built gets replaced badly because nobody thought to ask.

It costs almost nothing to set up and it's the kind of thing that only pays off occasionally, but when it does, it can be the difference between a resolved mystery and a permanent, expensive gap in institutional memory.

Why we're writing this up publicly

Every legacy modernization engagement we take on at 137Foundry starts with the same phase, before a single line of replacement code gets written: a structured audit of what the existing system actually does. Here's the process we've settled on after running this enough times to know which shortcuts are safe and which ones aren't.

Step 1: Map the system's actual footprint

Before anything else, we catalogue every input the system receives and every output it produces, including the quiet, undocumented ones. Legacy systems accumulate dependents nobody remembers: a nightly export a different team scripted against years ago, a manual report someone pulls quarterly. We've been burned before by assuming a system's "known" integrations were the only ones, so this step now gets a deliberate, checklist-driven pass rather than relying on whoever's currently around to remember them all.

Step 2: Interview everyone who touches the system, ranked by exposure

We start with whoever fields the most support tickets related to the system, since they've built the most current, continuously updated mental model of where it misbehaves. From there we work outward to finance or operations staff who consume its output, and finally to engineers who've patched it recently. Each layer surfaces a different kind of knowledge, and we've found that starting with support staff rather than engineers usually surfaces the most business-relevant edge cases fastest.

Photo by www.kaboompics.com on Pexels

Step 3: Read the code specifically for business logic, not architecture

A standard code review asks "is this well structured." Our audit read asks a different question: "what business decision does this specific conditional encode, and does anyone currently at the company know why." We flag anything that looks like a business rule rather than a technical necessity for follow-up in the interview phase, since code alone rarely explains its own motivation.

Step 4: Build a prioritized decision record, not an exhaustive one

Not every quirk deserves the same depth of investigation. We rank findings by how often they fire and how expensive a wrong answer would be, and we're explicit with clients that some low-frequency, low-stakes edge cases will get a lighter touch. Trying to fully resolve every single discovered oddity turns a two-week audit into a two-month one, and the marginal edge cases usually aren't where the real risk lives anyway.

Step 5: Confirm what's safe to drop, not just what to carry forward

A meaningful fraction of what an audit surfaces turns out to be dead logic: a rule that applied to a regulation, a promotion, or a business condition that no longer exists. We treat "we're deliberately not carrying this forward" as a valid, documented outcome, distinct from and much safer than silently dropping something during a code cleanup without ever confirming it was actually safe to lose.

How long this actually takes

Clients often ask for a time estimate up front, and the honest answer scales with how central the system is to daily operations, not with its raw line count. A system that touches a handful of internal reports might take a few days to audit thoroughly. A system that's core to billing, fulfillment, or regulatory compliance can reasonably take several weeks, since the interview phase alone requires scheduling time with people who have their own full workloads. We'd rather give a wider estimate up front than compress the audit later to hit an optimistic one.

What this buys the client

Clients sometimes push back on the time this phase takes, understandably, since it doesn't produce visible progress on the replacement system itself. What it buys is a specification for the new system that's actually complete, rather than one reconstructed purely from reading old code without the business context behind it. The alternative, skipping straight to the rewrite, tends to produce a technically clean replacement that quietly gets specific edge cases wrong for months after launch, which costs far more in incident response than the audit would have cost up front.

Where to read more

We've written up the fuller framework, including how the audit feeds into a parallel-run verification period before any legacy system actually gets decommissioned, in our guide on sunsetting a legacy system without losing institutional knowledge.

References

Wikipedia's entry on legacy systems covers general background on why these systems accumulate undocumented complexity.

Wikipedia's entry on knowledge management covers the broader discipline our audit process is a practical, narrow application of.

ISO's website maintains formal standards around organizational knowledge management for teams that want a more structured framework than an ad hoc process.

This audit phase is the least glamorous part of any legacy modernization project we run. It's also, consistently, the phase that determines whether the rest of the project goes smoothly or turns into a year of chasing down confusing edge-case bugs after the fact.

A habit we've picked up from doing this repeatedly

After running this process across enough different clients and systems, one pattern holds consistently: the clients who push back hardest on the audit timeline at the start are almost always the ones who end up most grateful for it once it surfaces something they genuinely didn't know about their own system. We've stopped treating that initial pushback as something to argue away up front and started treating it as something the audit itself resolves, once there's a concrete finding on the table instead of an abstract argument about process.

If you're on the client side of one of these engagements and feel skeptical about the time an audit is asking for, that skepticism is reasonable and worth voicing directly rather than quietly working around. The conversation that actually resolves it isn't us insisting the process is necessary in the abstract. It's agreeing on a small, time-boxed first pass and letting whatever it surfaces make the case for the rest.

We've come around to running that first pass as a fixed, capped engagement, a week, not open-ended, specifically so a skeptical client isn't being asked to commit to an unbounded process on faith. Once that first week produces something concrete, the conversation about the remaining scope gets a lot easier on both sides.

What we tell clients who want to skip straight to the rewrite

You should move from a monolith to microservices only when the change removes clear delivery, scale, resilience, or compliance bottlenecks. In fintech, the winning move is usually staged modernization, not a dramatic rewrite.

If you are leading a legacy transformation, you need a plan that protects uptime, controls risk, and improves delivery speed without creating service sprawl. This guide shows you where microservices help, where they hurt, how to modernize a fintech stack safely, and what your first year should actually look like when the goal is measurable progress rather than architectural theater.

Should A Fintech Company Really Move From A Monolith To Microservices?