Goldman Sachs engineers tackle legacy systems with incremental modernization

InvestOne, Goldman Sachs’ asset management ledger, sits at the heart of the firm’s middle office. The firm’s core platforms sit underneath trading, risk management, client services, reporting, and operational controls, so the work often starts with systems that cannot simply be shut down and rewritten. That reality changes what counts as good engineering inside a large bank: the people who move up are the ones who can improve fragile, high-stakes systems without interrupting the business.

What legacy really means at Goldman Sachs

In a Wall Street engineering shop, “legacy” is not just old code. It usually means a web of services, embedded rules, audit expectations, and business dependencies that have accumulated over years of regulation and market change. That is why modernization at Goldman Sachs tends to be incremental, carefully tested, and coordinated with business and compliance teams rather than framed as a dramatic rewrite.

The careers side of the house reflects that structure. Goldman Sachs hires engineers across Global Banking & Markets, Asset & Wealth Management, and Platform Solutions, and looks for people who can solve clients’ most complex challenges. In practice, that means engineers are expected to think beyond code quality alone and weigh continuity, controls, and how a system change will affect traders, operations staff, and client-facing teams.

That same pressure shapes the day-to-day judgment engineers need. Debugging matters, but so does patience with dependencies. Testing matters, but so does knowing when a small refactor is safer than a broad redesign. In a large financial institution, credibility often comes from showing that you can improve architecture without triggering a production incident or creating a downstream reconciliation problem.

The modernization playbook is usually small steps, not big rewrites

The patterns that show up in this environment are practical and familiar to anyone who has worked on critical infrastructure. Engineers refactor in small steps, wrap older services with APIs, add feature flags, improve observability, and move workloads only after parallel validation proves the new path behaves the same as the old one. Those choices are less glamorous than a clean rebuild, but they are the ones that earn trust in a regulated setting.

That trust matters because the audience for engineering work is wider than other technologists. A migration plan at Goldman Sachs may need to make sense to product managers, risk teams, operations staff, and business leaders who care more about stability than novelty. An engineer who can explain why a rollout is staged, how rollback works, and what controls are in place is often building the same credibility that later supports promotion into senior IC or management tracks.

The firm’s own job descriptions reinforce that split between technical depth and business impact. A Global Markets Trading Platform Engineering role in Dallas describes Goldman Sachs engineers as “innovators and problem-solvers” building solutions in risk management, big data, mobile and more. The same posting describes the team as building pre-trade workflow and trade execution platforms for salespeople and traders, which puts engineers directly in the flow of market activity rather than in a detached back-office support function.

InvestOne shows what mission-critical modernization looks like

During AWS re:Invent session FSI312 in December 2024, Goldman Sachs said InvestOne is responsible for calculating and maintaining investment portfolio positions. The session also said the firm migrated that mission-critical mainframe while working through scale, cost, and technical debt.

In a system like InvestOne, modernization cannot be separated from operational risk. Every move touches portfolio accounting, downstream reporting, and the controls that support them, which is why a migration has to be treated as a business continuity exercise as much as a software project. The same session also referenced Goldman Sachs’ COBOL development and deployment framework.

That work shows managers that you can handle complex dependencies, understand the cost of failure, and keep a transformation moving without overpromising. Teams are judged not only on shipping features but also on whether the firm can keep trading, reporting, and client operations running.

Legend is the example of moving from support to build

Goldman Sachs has also used its own developer messaging to describe how this shift changes the job itself. In a post on Legend, the firm wrote that engineering teams are now “free to build rather than support legacy code.” That line captures a real internal career divide: some engineers spend their time keeping old systems alive, while others get moved closer to new platform work once the old bottlenecks are tamed.

Legend was not just an internal tool. Goldman Sachs released its Legend data management system to the world so others could break down silos and make better financial decisions, Ephrim Stanley, a Technology Fellow at Goldman Sachs, wrote in a Google Cloud blog.

Engineers who can help turn an internal system into a cleaner platform get exposed to more of the business and more of the architecture. That can improve team credibility, widen exit opportunities into other large-scale financial infrastructure jobs, and create a stronger case in promotion reviews than staying narrowly tied to break-fix support.