Table of Contents

The Business-Critical Spreadsheet Nobody Owns

Every department has one. A workbook on a shared drive that quietly runs procurement, scheduling, or the monthly ops report your leadership team reads every Monday. Call it what it is: unowned software your team depends on daily, built by one person who never set out to write your department’s core system.

The risk is simple to state. The file behaves like production software, but nobody manages it like production software. There’s no version control, no backup owner, and no documentation beyond what lives in one person’s head. When that person is out sick, promoted, or gone for good, the workflow keeping your team running walks out with them.

This isn’t really a spreadsheet problem. It’s an operational continuity problem wearing a spreadsheet’s clothes, and most COOs don’t see it clearly until the person who built it is already halfway out the door.

The business-critical spreadsheet nobody owns: how a personal file became production software

Someone in ops built a tracker two or three years ago to solve one afternoon’s problem. Today it runs invoicing, inventory counts, and the report your CEO pulls up before board meetings. Nobody remembers approving that promotion.

It always happens the same way. A spreadsheet doesn’t get selected as business-critical infrastructure through a procurement process, a security review, or an IT sign-off. It earns the role gradually, one added tab and one new formula at a time, until the day someone realizes the whole department would stall without it. By then, walking it back feels riskier than living with it.

A department spreadsheet with dozens of interconnected tabs, showing how a business-critical spreadsheet grows past what any one person can safely maintain

Compare that to how actual production software gets built. Code goes through review before it ships. Changes are tracked and reversible. Someone other than the original author can read it and understand what it does. A spreadsheet running your department has none of that, even though it carries the same weight. It has become the system of record without ever earning the discipline a system of record requires.

The European Spreadsheet Risks Interest Group has studied this for two decades, and the finding holds across industries: a personal tool crosses into “everyone relies on it” territory long before anyone treats it with the rigor that status demands. Nexa Devs sees this constantly in mid-market ops teams. The file usually isn’t badly built. It’s just being asked to do a job it was never designed to hold.

Bus factor of one: the key-person risk hiding in your most critical file

Ask who else on your team can open your master spreadsheet and rebuild it from scratch. If the honest answer is nobody, you’re running a bus factor of one on a system your department can’t function without.

“Bus factor” comes from software engineering, and it measures something specific: the number of people who could disappear before a project stalls out completely. Even mission-critical open-source databases like MySQL and PostgreSQL, software running inside millions of companies, carry a bus factor of roughly two. Most department spreadsheets don’t even clear that bar. One person wrote the formulas, one person knows what the color coding means, one person remembers why row 40 has a manual override nobody else is supposed to touch.

Ryan Steil, CEO of Rhodium Digital, has watched this play out across client engagements: “Clients running $30 million operations on spreadsheets, duct-taped middleware, or an overworked Excel genius who holds the entire reporting process together through brute force and caffeine.” That genius is a real person on your payroll, and their knowledge has never been written down anywhere you could hand to someone else.

An empty desk representing the operational gap left when the one person who understands a critical spreadsheet is suddenly unavailable

What happens the week that person is out or leaves

The first missed day is manageable. Someone covers, badly, and the team apologizes to whoever’s waiting on the report. The real damage shows up when the absence stretches past a week: a parental leave, a resignation, a sudden illness. Formulas break silently. Nobody notices a dropped row until a customer calls asking where their order went.

Research cited by SHRM found that 72% of companies have at least one employee whose sudden departure would meaningfully disrupt operations. That isn’t a rare edge case. It describes most of the organizations reading this, right now, today.

Why “just have someone else learn it” doesn’t work

Cross-training sounds like the obvious fix until you actually try it. A spreadsheet’s real logic rarely lives in the formulas. It lives in the judgment calls: which exceptions get manual overrides, which numbers get quietly adjusted before the report goes out, which tab is safe to ignore. None of that is written anywhere. ClearlyAcquired’s research on key-person risk puts the cost of replacing that kind of embedded technical knowledge at 150 to 400% of salary, with new hires needing months to reach full productivity even after they’re hired. Cross-training assumes there’s a backup to build, when the real work is extracting tacit knowledge that was never designed to leave one person’s head.

What it’s actually costing you: errors, rework, and missed SLAs

A single mistyped formula can misstate a quarter’s numbers before anyone catches it. Put bluntly, that’s what a business-critical spreadsheet costs you, and it happens more often than your team probably realizes.

Academic auditing research going back decades, the kind EuSpRIG has built its entire body of work around, consistently finds error rates in active spreadsheets far higher than most finance and ops leaders expect. The exact percentage varies by study, but the direction never does: spreadsheets with real complexity, the ones with nested formulas and cross-tab dependencies, are error-prone by design, not by accident. JPMorgan’s 2012 “London Whale” incident traced part of a multi-billion-dollar trading loss back to a spreadsheet copy-paste error buried inside a risk model nobody had properly reviewed. The exact figures attributed to that error vary by source, but the incident itself is well documented.

You don’t need a trading floor for this to bite. Picture a mid-market operations team where the weekly inventory reconciliation runs through a shared workbook with six linked tabs. One dragged formula, and the whole week’s reorder quantities are off. Someone catches it Thursday. Now the team is rebuilding two days of work while the warehouse waits on a decision it should have had Monday. Multiply that by every department running the same setup, and the hours add up fast. It’s not one dramatic failure that sinks a business-critical spreadsheet. It’s the slow bleed of rework hours, missed handoffs, and preventive maintenance quietly skipped because nobody flagged the schedule change buried three tabs deep.

Why “just add more automation” makes it worse

More automation on top of a spreadsheet doesn’t remove the dependency. It adds another layer that still depends on the same one person to maintain, and now that person has two systems to hold in their head instead of one.

This is the trap most ops teams fall into, and it’s an understandable one. The spreadsheet is straining, so someone bolts on a macro, then a script that pulls data automatically, then a scheduled email that fires off the report. Each addition feels like progress. Each one is actually another point of failure stacked on the original single point of failure.

The workaround-on-a-workaround spiral

The pattern plays out predictably. The macro breaks when the source file’s column order changes. The scheduled script fails silently over a holiday weekend and nobody notices for three days. The automated email keeps sending, but it’s sending last week’s numbers because the underlying refresh quietly stopped working. None of these tools were built with monitoring, alerting, or a fallback plan, because none of them were built as software. They were built as patches on a patch.

We’d argue this is the single most expensive mistake a COO can make with a struggling spreadsheet: treating “add more automation” as a cheaper alternative to “replace the system.” It’s rarely cheaper. It just defers the cost and adds interest.

Where shadow automation and AI quietly enter

This is where AI tools have started showing up in ops workflows, usually without IT’s knowledge. An employee plugs a spreadsheet into an AI assistant to auto-generate a summary, or builds a lightweight automation using a no-code tool that connects to the same fragile file. It’s not malicious. It’s the same instinct that built the original spreadsheet: solve today’s problem with whatever’s on hand. But every one of these additions deepens the exact dependency it was meant to relieve, and now the knowledge required to maintain the system is spread across even more disconnected tools.

A tangle of connected automation scripts and AI tools all feeding off the same fragile spreadsheet, illustrating the workaround-on-a-workaround spiral

Why controls and governance don’t fix the underlying problem

Spreadsheet controls, version locking, sign-off workflows, contain the symptom. They don’t touch the reason the file exists in the first place.

Most organizations that take spreadsheet risk seriously eventually build a governance layer: an inventory of critical files, required approvals before major changes, periodic audits. These aren’t bad ideas. They genuinely reduce the odds of a catastrophic single error slipping through unnoticed. What they don’t do is answer the actual question a COO should be asking, which is why a spreadsheet is running a core department process instead of purpose-built software.

Controls manage risk within the workaround. They don’t remove the workaround. You can lock down who’s allowed to edit the master file and still have a system with a bus factor of one, because the underlying problem was never the lack of a sign-off process. It was that the real system, whatever platform your team is supposed to be using, doesn’t fit how the work actually happens. Read our breakdown of why spreadsheet-run operations break at scale Governance is worth doing. Just don’t mistake it for a fix.

Replacing the workaround layer with a system built around the workflow

The fix isn’t another SaaS subscription that promises to replace Excel. It’s a system designed around how your team actually works, not around a generic template built for a different company’s workflow.

That distinction matters more than it sounds like it should. Most off-the-shelf platforms fail the same way the spreadsheet eventually will: they don’t match the specific exceptions, approval chains, and edge cases your operation has accumulated over years. Teams end up building a new spreadsheet workaround around the new software within eighteen months. Same problem, prettier interface.

Designing around the actual workflow, not the tool

The starting point isn’t “what software should we buy.” It’s mapping what the spreadsheet is actually doing today, including the undocumented exceptions and manual overrides nobody wrote down. Nexa Devs starts every internal system engagement right here: AI-assisted requirements analysis surfaces the workflow logic buried in the file before a single line of code gets written, so the replacement system is built around how your team really operates, not around a guess at how it should.

Documentation and ownership you keep

The difference between Nexa’s approach, the spreadsheet, and a typical outsourced project shows up clearly here. Nexa delivers complete documentation, architecture diagrams, system design records, test coverage reports, unconditionally, whether or not the engagement continues afterward. That documentation belongs to your team from day one. Instead of trading a workaround only one person understands for a black box only one vendor understands, you own the system, fully, the same way you’d own a building instead of renting one you can’t ever quite leave.

A team reviewing a complete system documentation package, showing the ownership handoff that replaces a single person’s tacit knowledge

A phased cutover that doesn’t break operations

Nobody wants to flip a switch and hope the new system holds. A responsible cutover runs the replacement alongside the existing spreadsheet for a defined period, department by department, verifying each piece against the old process before retiring it. See how AI-augmented delivery shortens modernization timelines The spreadsheet doesn’t disappear on day one. It gets replaced piece by piece, with each piece proven before the last workaround gets turned off.

Is this slower than a big rewrite done all at once? Sometimes, by a few weeks. It’s also the difference between a modernization project and an outage you have to explain to your board.

FAQ

Table of Contents

SIS Migration in Higher Education: Modernize First

Anthology’s SIS and ERP business now belongs to Ellucian, and more than 260 higher education institutions woke up to a new vendor roadmap they never voted on. If your campus is one of them, the SIS migration higher education path you’re being handed by default runs 18 to 36 months and rarely holds to budget. That default isn’t your only option.

You can modernize and extend the systems your institution already owns, build an integration layer that keeps admissions, finance, and student records running through the transition, and come out the other side owning your data and your documentation instead of renting access to someone else’s platform.

This guide is for the IT Director or CTO who just learned their vendor’s roadmap changed hands, and for the President or CFO who has to approve whatever comes next.

Quick answer: modernize your SIS, don’t replace

1. Ellucian’s acquisition of Anthology doesn’t force your institution into a full SIS replacement. It’s a decision point.
2. Rip-and-replace SIS migrations run 18 to 36 months. Standard timelines rarely survive first contact with a real campus budget cycle.
3. An integration and data layer keeps admissions, finance, and records running while you evaluate options on your own schedule.
4. Modernizing systems you already own incrementally often costs less and disrupts less than a forced platform swap.
5. Complete documentation transfer during any migration work stops the institution from trading one vendor lock-in for another.

A mid-size university IT team reviewing what a vendor acquisition actually changes on campus

What the Anthology-to-Ellucian Consolidation Actually Means for Your Campus

Ellucian completed its acquisition of Anthology’s student information system and ERP business, folding in more than 260 institutions that had no vote in the matter. ERP Today reported it straight from the deal announcement page. If your campus ran Anthology Student, PowerCampus, or another product in that portfolio, your roadmap, your support contract, and your renewal terms all sit inside a different company now.

Anthology had been working through financial restructuring before the deal closed , and Ellucian picked up ownership of the ERP and SIS lines as part of that process. The question that matters for your institution isn’t the deal mechanics but whether your specific product sits on a roadmap Ellucian intends to keep funding, sunset gradually, or fold into its own SaaS platform on a timetable you don’t control.

PowerCampus customers in particular should ask their account team directly: is this product still on an active development roadmap, or is it being positioned as a migration path into Ellucian’s newer SaaS offering? Get that answer in writing. Don’t assume silence means stability.

The Rip-and-Replace Default: Why Standard SIS Migration in Higher Education Costs Years and Millions

A rip-and-replace SIS migration doesn’t start with a kickoff meeting. It starts with a vendor timeline that assumes your institution has years of runway and a budget line nobody’s touched yet.

The 18-to-36-Month Timeline Institutions Are Quietly Signed Up For

The standard phased approach vendors describe (data audit, cleansing, vendor selection, data mapping, test migration, parallel running, go-live) sounds orderly on a slide. In practice, a mid-size university runs this across multiple academic terms, because you can’t cut over admissions or financial aid processing in the middle of a semester. Most institutions default to this path anyway, mostly because nobody hands them an alternative framework until the vendor conversation is already underway.

Where the Budget Actually Goes (and Why It Overruns)

The education ERP market is projected to grow from $23.13 billion in 2026 to $41.18 billion by 2030, a 15.5% compound annual growth rate, according to Research and Markets. That growth comes from institutions signing new platform contracts, not from efficiency gains on old ones. Budget overruns on rip-and-replace projects typically come from three places: data remediation nobody scoped upfront, integration rebuilding for systems the vendor never audited, and staff retraining that gets underestimated by half. hidden tax of technical debt

Migration Is a Choice, Not a Sentence: A Decision Framework for Replace vs. Modernize

A vendor acquisition creates urgency. It doesn’t create an obligation. Your institution gets to decide whether the systems underneath your operations are actually failing, or whether you’re being pushed onto an acquirer’s rails on a timeline that serves their integration roadmap more than your campus.

Signs Your Systems Are Genuinely at End of Life

• Your vendor has confirmed, in writing, that support and security patches are ending on a specific date
• Core compliance requirements (FERPA reporting, financial aid processing rules) can no longer be met without custom workarounds
• The system can’t integrate with anything built after roughly 2015 without a consultant on retainer

Signs You’re Being Pushed Onto the Acquirer’s Rails Prematurely

• The “end of support” date keeps moving whenever you ask for specifics
• Your current system still meets FERPA, financial aid, and reporting requirements without modification
• The proposed replacement timeline was set by the vendor’s integration roadmap, not by an assessment of your actual systems

A simple framework campus IT leaders can use to separate genuine end-of-life systems from vendor-driven urgency

Which one are you actually looking at? Most mid-size institutions, when they run this checklist honestly, find they’re closer to the second list. EDUCAUSE publishes ongoing research on higher ed IT decision-making that’s worth reviewing before you commit either way.

Where Forced Migrations Actually Break: Data, Integrations, and Institutional Knowledge

Ask any registrar what happens the week after a legacy SIS goes dark, and you’ll hear about the spreadsheet that quietly reconciled financial aid disbursements for six years. That spreadsheet was never in the migration scope document. It never is.

Data Migration and Data Quality

Years of manual corrections, duplicate student records from merged systems, and inconsistent course numbering all get inherited by whatever replaces your SIS. A rushed migration doesn’t clean that up. It just moves the mess to a new platform with a shinier interface.

The One-Off Integrations Holding Admissions, Finance, and Records Together

According to ListEdTech, 19% of higher education institutions run a homegrown grant management system, compared with just 1 to 5% for most other administrative categories, the highest homegrown share of any system type on campus. Those tools rarely show up in a vendor’s migration scope document, and they’re exactly the integrations that break first when a platform changes underneath them.

The Undocumented Knowledge That Leaves When the Platform Does

The person who knows why the financial aid export runs at 2 a.m. instead of during business hours usually isn’t in the migration planning meetings. When that person retires or leaves mid-project, the reason leaves with them. 1EdTech maintains interoperability standards that can reduce how much of this knowledge lives only in one person’s head, but only if your integration layer is built to use them.

The Integration and Data Layer That Keeps Your Campus Running Through the Transition

An integration layer has one job during a vendor transition: keep admissions, finance, and student records talking to each other while the platform question gets resolved on your own schedule, not the acquirer’s.

This is middleware work, not platform work. You build APIs that sit between your existing SIS, your finance system, and your student records, so daily operations don’t depend on any single vendor’s roadmap staying stable. Martin Fowler’s strangler fig pattern describes the underlying approach well: you route traffic through a new layer incrementally, replacing pieces of the old system as they’re actually ready, rather than freezing operations for a big-bang cutover.

For a registrar’s office, this looks like an API that keeps enrollment data synchronized correctly even if the underlying SIS product’s support status changes twice during your evaluation period. For finance, it means disbursement processing keeps running whether or not you’ve decided on a replacement platform yet. vendor handoff checklist

Modernize and Extend What You Already Own, Incrementally

Incremental modernization isn’t about nursing broken systems along for another year. You replace the parts that are actually failing, one module at a time, while everything else keeps working.

Start with an architecture assessment that maps which parts of your current SIS environment are genuinely at risk versus which ones just look old. Nexa Devs has run this kind of work inside institutions like UNED, Europe’s largest distance-learning university, absorbing years of growing system complexity without forcing a full platform swap or a proportional expansion of internal IT headcount. The pattern holds in higher ed generally: modernize the module that’s actually failing, test it against live operations, and move to the next one only once the first is stable.

A phased modernization path that replaces failing modules one at a time instead of the whole platform at once

This approach costs less than a full rewrite for a simple reason: you’re not paying to rebuild what already works. You’re paying to fix what doesn’t, with AI-assisted architecture analysis and testing built into every phase instead of bolted on at the end.

Owning Your Systems and Your Documentation: Never Captive to One Vendor’s Roadmap Again

The Anthology-to-Ellucian consolidation is what vendor lock-in looks like from the outside: a decision made somewhere you weren’t in the room, executed on a timeline you didn’t set.

As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another.” That’s the trap worth naming directly: swapping vendors without changing the underlying dependency doesn’t solve anything. It only resets the clock on the next forced migration.

Pragmatic Coders puts it precisely: legal IP ownership isn’t the same as practical operational control. You can own the contractual rights to your data and still be functionally locked out if nobody on your team, or your partner’s team, ever documented how the pieces connect. Dreamix has documented the same failure mode from the other direction: documentation gaps and undocumented dependencies create expensive problems months after a transition completes, long after anyone thought to check.

Complete documentation, architecture diagrams, data schemas, integration maps, transferred to your institution at every project milestone instead of buried in a final deliverable, is the structural fix. institutional knowledge loss

Building the Business Case for the President and CFO

Your CFO doesn’t need architecture diagrams. They need three numbers, side by side: what doing nothing costs, what rip-and-replace costs, and what incremental modernization costs.

1. What doing nothing costs. Ask what happens to compliance, financial aid processing, and reporting accuracy if support genuinely ends on your current product with no plan in place.
2. A full rip-and-replace typically runs into seven figures once staff time, data remediation, and multi-year vendor fees are counted, not just the software license.
3. Incremental modernization spreads cost across budget cycles instead of requiring one large capital approval, and it doesn’t require freezing all other IT projects for two to three years while the migration runs.

NACUBO publishes budget planning frameworks that can help translate this into language your board will recognize. A full rip-and-replace is rarely the right call for a mid-size institution mid-transition. Modernizing what you already own, on your own schedule, almost always is.

A comparison of doing-nothing, rip-and-replace, and incremental modernization costs prepared for a board presentation

Nexa Devs builds the integration and data layer that keeps your campus running through a vendor transition, modernizes the systems you already own instead of forcing a rebuild, and transfers complete documentation at every milestone so your institution owns what it’s paying for. Schedule an architecture assessment to map what’s actually at risk in your current SIS environment before your next contract renewal deadline forces the decision for you.

FAQ

Table of Contents

AI Agent Access Control: Fixing the Plumbing Gap

Every mid-market engineering team runs the same experiment. Connect an AI agent to a few internal systems, watch it work, celebrate the demo. Then someone asks what happens if the agent misfires for ten minutes with the credentials it currently holds, and the room goes quiet.

AI agent access control means giving each agent its own scoped, least-privilege identity instead of a shared API key, so it can only reach the specific systems and actions its task requires, and every action it takes gets logged and attributed to that identity. Most mid-market pilots skip this step. They wire an agent to a single service account with broad permissions because that’s the fastest path from prototype to demo, and that shortcut is what turns a working pilot into a security incident.

The problem isn’t the model. It’s the access surface underneath it, built for humans clicking through a UI one action at a time, not for software calling it thousands of times a minute with nobody watching. Fixing that surface, not restricting what the AI is allowed to think, is the actual engineering work ahead.

Quick answer: securing AI agent access control

1. Give every agent its own scoped identity. A shared API key means one bad prompt can reach everything that key touches.
2. Apply least-privilege by default. An agent should only call the specific endpoints its task requires, nothing broader “just in case.”
3. Build a safe-access layer with APIs and MCP-based tool interfaces over legacy systems instead of granting raw database or admin access.
4. Log every agent action to a per-identity audit trail, so you can answer “what did this agent do” in seconds, not weeks.
5. Require human approval for irreversible actions: large transfers, deletions, or external messages sent on your behalf.

A visual comparison of a shared API key versus scoped, per-agent identities with individual permission boundaries

Why Every Agent Pilot Becomes a Breach Waiting to Happen

Set an over-permissioned agent loose with untrusted input and outbound access, and you don’t need a sophisticated attacker. A single malformed customer email can trigger it. Security researchers call this combination the lethal trifecta: private-data access, exposure to untrusted content, and the ability to take outbound action, all held by one agent at once.

The scale of the agent-security gap

Production security posture for AI agents is worse than most CTOs assume. Help Net Security’s 2026 research found that only 11% of production AI agents land in what researchers call the Fortified Leaders quadrant, where high attack surface meets strong defenses. The other 89% carry more access than their defenses can justify.

That gap isn’t evenly distributed. It concentrates hardest in mid-market environments, where a small platform team gets asked to wire agents into ERPs, CRMs, and internal tools that were never built with an API-first mindset. Nobody sat down and decided to grant an agent broad access. It accumulated one integration ticket at a time, the same way technical debt always does.

We’ve watched this happen inside client environments more than once: a proof-of-concept agent gets a “temporary” admin token to unblock a demo, the demo succeeds, the token quietly becomes permanent. Six months later, nobody on the team remembers why it has the scope it does. It just works, so nobody touches it.

The “lethal trifecta”: private-data access, untrusted input, and outbound actions

A support agent with read access to customer records, an inbox to monitor, and reply authority is a lethal trifecta walking around loose. An attacker doesn’t need to breach your network. They just need to email the agent something that looks like an instruction.

Help Net Security reported on a mid-sized company where an AI agent kept using an expired credential nobody had logged, reaching customer records, source code, and HR files for an entire quarter before anyone noticed. Nobody revoked the access, because nobody was tracking that the agent had it in the first place.

This is the failure mode the rest of this piece addresses: not a smarter attacker, but an access surface nobody mapped. Restricting what an agent is capable of reaching is a plumbing problem, not a model problem, and it needs to be solved with the same rigor you’d apply to any privileged system account. why legacy systems block AI agent deployment

Anatomy of an Over-Permissioned Agent

Over-permissioning rarely happens on purpose. It happens because scoping access properly takes real engineering time, and shipping the demo doesn’t wait for it. Three patterns show up again and again.

The single shared API key shortcut

One key. One service account. Every agent action, every integration, every tool call routes through the same credential. It’s the fastest way to get an agent working across five systems by Friday, and it’s also the fastest way to make a single leaked secret catastrophic.

When every agent shares one identity, you lose the ability to answer a basic question during an incident: which agent did this? A shared key collapses five distinct actors into one undifferentiated blob of access. You can revoke the key, but you can’t selectively revoke just the piece that misbehaved without breaking everything else that depends on it.

Nexa’s engineering teams see this pattern constantly in mid-market codebases that were never built expecting programmatic callers. The workaround someone reached for under deadline pressure becomes the permanent architecture, because nobody schedules time to go back and fix it once the demo works.

Standing and expired credentials no one logs

Human employees get offboarded. Their accounts get disabled, their badges get deactivated, someone checks a box. Agent credentials almost never go through an equivalent process, because most organizations don’t treat non-human identities as identities that need a lifecycle at all.

That’s how you end up with the exact scenario Help Net Security documented: a credential expires on paper but keeps working in practice, because the system issuing it never enforced the expiration and nobody was watching the logs closely enough to notice. The agent didn’t do anything malicious. It just kept using access nobody remembered granting.

Standing credentials, ones that never expire and never get reviewed, are the single most common finding when Nexa’s teams run an architecture assessment on a client’s agent integrations. They’re rarely flagged as a problem until an audit or an incident forces the question.

How prompt injection weaponizes excess permissions

Prompt injection is the mechanism that turns excess scope into a live incident, and it stopped being hypothetical a long time ago. An attacker doesn’t need your credentials if your agent already has broad ones and can be tricked into using them.

A well-scoped agent that gets successfully prompt-injected can still only do limited damage, because its access ceiling caps the blast radius. An over-permissioned agent that gets injected can do almost anything a human administrator could do, at machine speed, without a human in the loop to notice something’s off. The vulnerability class is the same either way. The consequence is entirely a function of scope.

An illustration of how a malicious input can trigger unauthorized actions when an agent holds excess permissions

Why Mid-Market Internal Systems Can’t Safely Be Called by an Agent

Your ERP was built for a person clicking buttons, not for software issuing thousands of calls a minute. That mismatch, not the AI model, is the real reason mid-market agent pilots keep producing over-permissioned access.

Systems never designed for programmatic access at scale

Most mid-market internal systems, the finance platform, the practice management tool, the operations database, were built fifteen or twenty years ago around a human sitting at a screen. Authentication assumed a person typing a password. Authorization assumed a role assigned to an employee. Rate limits, if they exist at all, assume human typing speed.

An AI agent breaks every one of those assumptions. It doesn’t log in once a day. It calls the same endpoint hundreds of times in a single task. It doesn’t have a “role” in the HR sense, so someone has to invent one, and under deadline pressure the invented role is usually “give it whatever the admin has.”

David Burg, Cybersecurity Leader at Ernst & Young Americas, put the underlying issue plainly: “One of the challenges with legacy systems is that an accumulation of technical debt amasses over time. When they were built, developers were working with the institutional knowledge that existed at that time. The documentation of architecture, interoperability, and dependencies and such were likely never documented.” An agent trying to call into that undocumented system inherits every one of those gaps.

The legacy-integration bottleneck that forces the shortcut

The average enterprise runs on nearly 900 applications, and only about a third of them are properly integrated, according to Salesforce research. Every one of those unintegrated systems is a wall an agent has to get through somehow, and the fastest way through a wall with no door is to borrow the master key.

That’s the trap. Building a proper scoped interface for one legacy system takes weeks of engineering work. Grabbing an existing admin credential takes an afternoon. Under a deadline, the second option wins almost every time, and the resulting integration quietly becomes permanent infrastructure instead of the temporary hack it was meant to be.

This is precisely the gap Nexa’s engineering process is built to close: architecture assessments that map exactly which legacy systems an agent needs to reach, followed by scoped API and middleware work that gives it a real door instead of a stolen key. It doesn’t require ripping out the underlying system, only wrapping it with an interface that was designed for this use case instead of retrofitted under pressure. the hidden cost of unaddressed technical debt

Treat Every Agent as a First-Class Non-Human Identity

Stop thinking of an agent’s credentials as a technical detail and start thinking of the agent itself as an employee who needs onboarding, a defined role, and an offboarding process. That reframe changes almost everything about how the access gets built.

Per-agent scoped identities, not a shared key

Every agent, every tool, every integration should authenticate as itself, not as a shared service account. A billing agent gets an identity scoped to billing endpoints. A support agent gets a separate identity scoped to support tools. If one is compromised, the blast radius stops at the boundary of what that specific identity can reach.

None of this is new. Organizations already apply the same principle to human employees: an intern doesn’t get the CFO’s login. Non-human identities deserve the same discipline, and most mid-market environments simply haven’t extended it that far yet.

Least-privilege by default

Default every new agent integration to zero access, then grant exactly the permissions its specific task requires, nothing broader “for flexibility” or “in case we need it later.” Flexibility granted in advance is the surface a future prompt injection will exploit.

Least-privilege has to survive the agent’s entire lifecycle, not just its first setup. When its task changes, its scope should change with it, and permissions it no longer needs should get revoked rather than left in place because nobody wanted to risk breaking something.

Zero trust for non-human identities

Zero trust architecture, don’t automatically trust any request regardless of where it originates, verify continuously, applies at least as strongly to agents as it does to human users. NIST’s Zero Trust Architecture guidance (SP 800-207) treats every access request as untrusted until proven otherwise, and that standard doesn’t carve out an exception for software callers.

In practice, this means an agent’s identity gets verified on every call, not once at session start, and that verification checks not just “is this a valid credential” but “does this specific action fall within this identity’s current scope.” An agent that’s normally scoped to read-only reporting shouldn’t be able to trigger a write action just because its credential happens to still be valid.

A diagram showing continuous verification checkpoints for a non-human identity across multiple system calls

Build a Controlled Access Surface with APIs and Middleware

Give the agent a door, not a master key. That’s the entire architectural shift: a scoped interface layer between the agent and your legacy systems, instead of direct, unmediated access to the systems themselves.

A scoped safe-access layer over legacy systems

You don’t rebuild your ERP or your practice management platform. You build a thin, purpose-designed layer of APIs and middleware that sits in front of the legacy system and exposes only the specific operations an agent is allowed to perform. The legacy system stays exactly where it is. The agent never touches it directly.

This is the work Nexa delivers as standard on integration engagements: APIs and middleware that connect disparate internal systems, scoped to what each caller specifically needs rather than opened broadly because that was easier to configure. It’s engineering discipline applied to a new class of caller, not a new discipline invented from scratch.

MCP-based tool interfaces for auditable actions

Model Context Protocol gives agents a standardized way to call tools, and that standardization is itself a security win: every tool call becomes a discrete, loggable, scopeable event instead of an opaque database query buried inside application code. When an agent’s access is expressed as a defined set of MCP tools, you can see, name, and limit exactly what it’s capable of doing.

An over-permissioned MCP configuration is still possible. Exposing a generic “run this SQL” tool defeats the entire purpose of the pattern. A well-scoped configuration exposes named, narrow tools instead: “look up customer by ID,” not “query the database.” Nexa’s delivery teams use MCP-based integrations as a core engineering workflow specifically because that granularity makes least-privilege enforceable rather than aspirational.

Least-privilege scoping without a full rewrite

You don’t need to replace the underlying system to fix this. A scoped API and middleware layer can go live in weeks, not the years a platform rip-and-replace would take, because it wraps the existing system instead of rebuilding it. That’s the practical argument for a mid-market CTO who doesn’t have the runway or the risk tolerance for a big-bang migration.

Skylar Roebuck, CTO at Solvd, frames the underlying risk this way: “Traditional modernization tends to over-index on protecting how things work today rather than building for what’s next. AI capability is compounding rapidly, and the real risk for mid-market companies is delay.” Every quarter spent without a scoped access layer is a quarter of accumulated exposure, not a quarter of safety bought by inaction. how legacy stacks block AI agent deployment

Make Every Agent Action Auditable

If you can’t answer “what did this agent do yesterday” in under a minute, you don’t have an audit trail. You have logs somewhere that nobody has time to read until after something has already gone wrong.

Per-identity audit trails

Every action an agent takes should write to a log tied to that agent’s specific identity, not a shared application log where its calls blend into everyone else’s. That per-identity trail is what lets a security team answer the only question that matters during an incident: exactly which actions did this specific agent take, in what order, against what data.

This is where scoped identities and audit logging reinforce each other. A shared credential produces a shared, ambiguous log. A per-agent identity produces a clean, attributable one. You can’t build accountability on top of an architecture that never separated the actors in the first place.

Documenting what each agent can and cannot reach

Every agent in production should have a written, current answer to a simple question: what can it reach, and what can’t it? Not a diagram from the kickoff meeting eighteen months ago. A living document that gets updated the moment scope changes.

This is where Nexa’s standard delivery practice becomes a security control rather than a nice-to-have: complete documentation transfer, UML diagrams, API references, architecture decision records, applied specifically to what each agent identity can and cannot touch. When that documentation stays current and lives with the client rather than locked in a departed vendor’s head, a new engineer or a security auditor can answer “is this agent over-scoped” without reverse-engineering the integration from scratch.

Runtime Monitoring and Human-in-the-Loop for High-Impact Actions

Scoping access at setup time isn’t the finish line. An agent that behaved normally for six months can start behaving abnormally the moment its prompt changes, its upstream data source gets compromised, or someone quietly widens its permissions to unblock a ticket.

Behavioral monitoring and anomaly detection

Watch for what changed, not just what happened. An agent that normally makes twenty calls a day and suddenly makes two thousand is worth a look, even if every individual call is technically within its scope. Volume and pattern shifts catch problems that permission checks alone will miss.

Runtime monitoring for agents borrows heavily from existing SIEM and behavioral analytics practice for human users. The difference is baseline: an agent’s “normal” behavior is far more predictable than a human’s, which actually makes anomalies easier to spot once you’re looking for them.

Approval flows for irreversible actions

Not every action deserves the same trust level. Reading a report and wiring $50,000 are not the same category of risk, and they shouldn’t route through the same approval path. Draw a hard line around actions that can’t be undone, large financial transfers, permanent deletions, external communications sent under your company’s name, and require a human to click “approve” before they execute.

This is the same control you’d apply to a new hire in their first week: full trust for reversible, low-stakes work, a second set of eyes on anything that can’t be walked back. Multi-agent setups raise the stakes further, since one agent’s output can become another agent’s trusted input; the same approval discipline should apply anywhere an irreversible action sits downstream of automated reasoning.

If your team is still deciding whether to build this layer in-house or bring in a partner who’s already done it, our piece on what actually blocks AI agents from reaching production walks through the infrastructure gaps that show up first.

What a Controlled Agent Surface Looks Like in Practice

The answer is not “don’t deploy agents.” That advice is both unrealistic and, frankly, bad business guidance in 2026. The fix is giving agents a controlled surface to act on: scoped identities instead of shared keys, MCP-based tool interfaces instead of raw database access, audit trails instead of silence, and human approval on anything irreversible.

None of that requires ripping out the systems your business runs on today. It requires an API and middleware layer purpose-built for this new class of caller, engineered with the same rigor you’d apply to any system handling customer data. That’s engineering work Nexa delivers as a standard part of how we build, not an add-on security product bolted onto a finished pilot after the fact.

A CTO who ships this layer before the next agent pilot isn’t slowing the roadmap down. They’re the reason the roadmap survives its first incident intact. Ready to see exactly where your systems stand? book an architecture assessment

An overview diagram of a complete controlled access surface, from scoped identity through audit trail to human approval

FAQ

Table of Contents

Legacy Migration Strategy: Big-Bang vs Incremental

A legacy migration strategy comes down to one choice: replace everything on a single cutover date, or replace the system piece by piece while it keeps running. The first approach is a big-bang rewrite. The second is incremental migration, usually built on the strangler fig pattern. For most mid-market companies, incremental wins.

Big-bang rewrites fail at a rate that should alarm any CEO signing the budget, and the reason is structural rather than bad luck. Teams start rebuilding before they understand what the current system actually does, then bet the entire project on one delivery date set eighteen months out. Incremental migration avoids both mistakes. You map the system before touching it, and you ship value in gated phases the board can actually see.

This guide covers why big-bang rewrites fail so often, how the strangler fig pattern works mechanically, and how to sequence an incremental roadmap that doesn’t stall halfway through.

Quick answer: choosing your legacy migration strategy

1. Big-bang rewrites replace everything on one cutover date. Incremental migration replaces the system piece by piece while the old one keeps running.
2. Big-bang rewrites fail more often because teams start rebuilding before they understand what the current system actually does.
3. Incremental migration gives a CEO value-gated milestones the board can see, instead of one high-risk delivery date eighteen months out.
4. The strangler fig pattern routes traffic gradually from old code to new code, so every cutover stays reversible.
5. Most mid-market teams should default to incremental delivery. A full rewrite is only defensible for small, isolated, well-understood systems.

A side-by-side view of the two migration paths: one high-risk cutover date versus a series of smaller, reversible phases

The Real Reason Modernization Projects Stall

A CTO at a 200-person logistics firm once told us her team hadn’t shipped a customer-facing feature in four months. Nothing had broken. Nothing had shipped either. Every sprint went to keeping the current system running.

That’s the legacy tax at work: the slow transfer of engineering capacity from building new things to defending old ones. CIO Dive’s analysis of enterprise IT spending found teams sending 43% of budget to legacy maintenance and just 29% to transformative technology work. The rest goes to keeping systems compliant, patched, and barely stable.

The tax compounds every year a system goes unaddressed. Dependencies get more tangled. The people who understand the original design get harder to reach. Boards start asking why velocity keeps dropping, and engineering leaders start dreading that question, because the honest answer (most of our capacity goes to holding the current system together) doesn’t sound like a plan. It sounds like an excuse.

This is the moment most companies decide to modernize. It’s also the moment they make the decision that determines whether the project ships or stalls: how do you get from the system you have to the system you need?

Big-Bang Rewrite vs Incremental Migration: What the Choice Actually Means

Two paths exist for retiring an aging system, and only one lets you change your mind halfway through. Both start from the same diagnosis. They diverge completely on execution.

This isn’t the classic “rewrite vs. refactor” debate that plays out inside a single codebase, where a team decides whether to clean up one module or start it over. Here you’re deciding how to retire an entire legacy platform, and that decision shapes budget, timeline, and risk for the next one to two years.

The big-bang rewrite: one date, all-or-nothing

A big-bang rewrite builds the replacement system in parallel, off to the side, while the legacy system keeps running production unchanged. Nothing goes live until the new system is judged “done.” On cutover day, traffic switches all at once. The old system gets retired, usually within weeks.

It’s the approach most people picture when they hear “system migration process.” It’s also a lift-and-shift in the worst sense: everything moves at once, on a single date, with no partial credit for getting most of it right.

The incremental path: replace in place, piece by piece

Incremental migration replaces functionality in slices. One workflow, one module, or one customer segment moves to the new system while everything else keeps running on the old one. Both systems coexist for months, sometimes longer, connected by a routing layer that decides which system handles which request.

This is the phased migration approach behind the strangler fig pattern, which we’ll walk through mechanically in the next section. The short version: you never bet the whole project on one date, because there is no single date.

A timeline view comparing a single high-stakes cutover date against a sequence of smaller, independently tested cutovers

Why Big-Bang Rewrites Are the Most Common Way Modernization Dies

Big-bang rewrites fail at a rate that should worry anyone signing the check. Hypertrends’ 2026 research found that big-bang modernization projects fail more than 70% of the time, whether “fail” means over budget, past deadline, or quietly shelved. That number holds up against what we see across mid-market engagements: the pattern is structural, not situational.

The comprehension gap: starting before you understand the system you have

Most rewrite projects start with a requirements document, not a system audit. Nobody maps what the current codebase actually does before deciding what the new one should do instead. Edge cases that took years to discover in production get rediscovered the hard way, usually after launch, usually by an angry customer.

As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another. Adding vendors and consultants often compounds the problem, bringing in new layers of complexity rather than resolving the old ones.” A rewrite built on an incomplete understanding of the original system doesn’t remove the legacy tax. It just moves into a newer building.

The single-cutover risk: everything rides on one delivery date

TSB Bank’s 2018 core banking migration is the case study every CTO in financial services already knows. On cutover weekend, a large share of TSB’s customer base lost access to online and mobile banking, and the outage stretched on for weeks. The financial and regulatory fallout, later covered extensively by the Financial Times and the BBC, ran into the hundreds of millions of pounds.

A single cutover date means every risk in the project (technical, operational, and organizational) lands on the same day. There’s no partial rollback, no gradual detection of what broke. There’s a go-live and a postmortem.

How the Strangler Fig Pattern Works in Practice

Martin Fowler, who named the pattern, borrowed the term from a vine that grows around a host tree until the original tree is gone and the vine stands on its own. Fowler’s original description frames incremental replacement as a discipline, not just a scheduling choice.

Routing and the facade layer

A facade layer sits in front of both systems and decides, request by request, which system handles the work. Early on, almost everything routes to the legacy platform. As new functionality ships, more traffic routes to the new system, one endpoint or one workflow at a time. Users never see the switch. They just notice, eventually, that features ship faster.

This is the same mechanism behind a monolith to microservices migration, except the target architecture doesn’t have to be microservices. It can be a modern monolith, a modular service layer, or anything else that fits the team’s operating model. The facade is what makes the migration incremental. The target architecture is a separate decision.

Parallel running and reversible cutovers

Each slice of functionality runs in parallel for a defined window before the old path gets retired. If something breaks, the facade routes traffic back to the legacy system in minutes, not weeks. Nobody is betting the business on a single migration event, because there isn’t one. There are dozens of small, individually reversible ones.

How a routing layer gradually shifts traffic from the old system to the new one, keeping each cutover reversible

What Incremental Delivery Gives a Non-Technical Budget Owner

A big-bang rewrite gives the board one report: green until the day it’s red. Incremental delivery gives a dozen reports, each one gated to a milestone the board can actually see and evaluate on its own merits.

Value-gated milestones the board can see

Every phase of an incremental migration ships something real: a workflow that’s faster, a report that’s more accurate, a feature the old system couldn’t support. The CEO isn’t asked to trust an 18-month plan on faith. Each phase either delivers the value it promised or it doesn’t, and the next phase gets funded, adjusted, or paused based on evidence instead of a sunk-cost bet.

Technical debt doesn’t just slow down engineering. AEI’s 2025 analysis puts the annual cost of unaddressed technical debt to the US economy at roughly $2.41 trillion. It’s the number a board sees when nobody acts. Value-gated milestones are how you show a board that action is producing something measurable instead of just spending against that number.

Accountability at every cutover, not one delivery date

A big-bang rewrite typically ends with a single handoff: the vendor delivers, invoices, and moves on. If the system fails six months later, who answers for it depends on the contract, and contracts written before launch rarely cover problems discovered after. This is where Nexa Devs’ engagement model diverges from a standard project vendor. Every phase runs under the same SLA-based partnership, so accountability doesn’t reset at each cutover. And because documentation transfers to the client unconditionally at every stage, not just at final delivery, each phase is something the client actually owns and can operate without Nexa in the room. Reversibility here isn’t only architectural, it’s contractual.

Choosing Your Path: A Decision Framework

Incremental is the safer default for most mid-market teams. A rewrite still makes sense, but only in a narrow set of cases, and pretending otherwise is how projects end up as another Hypertrends statistic.

When a rewrite is actually defensible

A full rewrite makes sense when the system is small enough to fully understand in a few weeks, isolated enough that few other systems depend on it, and either already failing outright or built on a platform nobody can hire for anymore. Under those conditions, the comprehension gap shrinks and the single-cutover risk shrinks with it. Replatforming versus re-architecture becomes a much smaller decision when the blast radius is small.

When incremental is the safer default

Everywhere else, incremental wins. Systems tightly coupled to other internal tools, systems processing regulated or customer-facing transactions, and systems nobody on the current team fully understands are exactly the cases where a single cutover date is the riskiest possible plan. Deloitte’s research, cited by Aalpha, found that phased modernization led to a 25 to 40% reduction in IT operational costs over three years compared to rip-and-replace approaches.

As Skylar Roebuck, CTO at Solvd, puts it: “Traditional modernization tends to over-index on protecting how things work today rather than building for what’s next. AI capability is compounding rapidly, and the real risk for mid-market companies is delay.” Most people read incremental as the cautious option. In practice it’s the one that keeps you shipping while the rest of the system catches up.

A simple decision tree: system size, coupling, and current failure state determine which migration path fits

Sequencing an Incremental Modernization Roadmap

Skip the comprehension phase and every phase after it inherits the same blind spot. Map the system first. Everything else in the roadmap depends on that map being accurate.

Comprehension first: map what exists before you touch it

Before any code moves, document what the current system does: its dependencies, its undocumented business rules, and the workflows nobody wrote down because the person who built them never left. This is usually the slowest part of a manual modernization effort, and it’s also where an AI-augmented delivery process earns its keep. how incremental AI integration works without a full rewrite Automated dependency mapping and code analysis compress a comprehension phase that used to take months into weeks, without skipping the step that big-bang projects skip.

Prioritize by risk and value, not by what’s easiest

The instinct is to migrate the easiest module first, because it feels like progress. Better sequencing prioritizes by a combination of business risk and business value: which workflow, if migrated successfully, proves the pattern works and unlocks the most value for the least exposure? That module becomes phase one, not because it’s simple, but because getting it right builds the case for phase two.

What You Gain After Escaping the Legacy Tax

Feature velocity comes back first. Maintenance cost drops months later, once enough of the legacy surface area has actually shrunk.

Teams report shipping features in weeks that used to take a quarter, simply because engineers are no longer routing around a system they don’t fully trust. The legacy modernization market itself reflects how widespread this shift has become. Mordor Intelligence projects the global legacy modernization market to reach $29.39 billion in 2026, up from $24.98 billion the year before, as more mid-market companies decide the cost of standing still now exceeds the cost of moving.

The bigger shift is less visible on a spreadsheet. Systems built or modernized through an incremental, well-documented process are ready for the next thing, whether that’s an AI feature, a new integration, or a team that didn’t build the original system taking it over without months of archaeology. the hidden tax of technical debt and what it costs every year you wait That readiness, not just lower maintenance cost, is what actually justifies the migration.

Choosing a legacy migration strategy isn’t really a technology decision. It’s a risk management decision that happens to involve technology. Big-bang rewrites bet everything on a date. Incremental migration, built on comprehension first and reversible cutovers, bets on a process instead. Talk to Nexa Devs about a phased legacy migration roadmap →

FAQ

Table of Contents

Institutional Knowledge Loss: The Two-Week Handover Myth

Institutional knowledge loss is what happens when the people who understand how your systems actually work leave, and nobody else can explain the decisions buried in the code. Two weeks of notice feels like plenty of time to hand things off. It seldom is. The knowledge that keeps your internal systems running lives inside one person’s head, accumulated over years of decisions that went undocumented as they were made. So when that person resigns, the clock that matters runs on a different question than fourteen days: how much of that knowledge you can still reconstruct once they’re gone. For most companies the honest answer is: not much.

This piece walks through why the standard handover fails as a matter of structure rather than effort, and what actually closes the gap: documentation your business owns from day one, paired with a partner accountable for keeping it current.

Quick answer: institutional knowledge loss risk explained

1. A two-week notice period cannot transfer years of undocumented decisions. The timeline itself is the structural problem, not the effort behind it.
2. Most critical system knowledge is tacit, meaning it’s the “why,” not the “what.” Handover sessions capture task lists, not reasoning.
3. Bus factor of one, where one person’s exit could stall the system, is a board-level risk, not an IT inconvenience.
4. Owned documentation, including UML diagrams, ADRs, API references, and test coverage, delivered on day one removes the single point of failure.
5. Long-term embedded partnerships accumulate knowledge continuously, so it never depends on any one person’s exit timeline.

What Really Leaves When Your Key Developer Gives Notice

Your best engineer just gave notice. She built the order-routing system three years ago, patched it through two acquisitions, and is the only person who knows why a specific validation rule exists. In fourteen days, that reasoning walks out with her, whether or not she runs a handover session.

Every mid-market company carries at least one version of this story, and there’s usually no villain in it. An ordinary technical hire becomes the sole owner of critical context, without anyone ever deciding it should work that way. The system runs. The dashboards look fine. Then the resignation letter lands, and the company discovers it doesn’t actually understand what it depends on.

The code stays on the server. What walks out the door is the reasoning behind it: why the team chose that database over the obvious alternative, why a workaround exists for a vendor bug from three years ago, why a particular integration has a retry loop nobody remembers writing a ticket for. That reasoning lives in one head, recorded in no commit message, and that head just handed in a resignation letter.

So what does that actually cost the business?

A single resignation can strand years of undocumented system context overnight.

The True Cost of Losing the Only Person Who Understands Your System

Replacing a senior technical hire costs more than the recruiting fee. ClearlyAcquired’s analysis of key-person risk puts the full cost, including lost productivity and delayed projects, at 150% to 400% of the departing employee’s salary, and new hires typically need 16 to 20 weeks to reach full productivity on a system they didn’t build.

The replacement and rehiring bill

That range holds up for most mid-market companies. SHRM found in 2023 that 72% of organizations have at least one employee whose sudden departure would meaningfully disrupt operations. That’s nearly three out of four companies running on a dependency nobody has priced. A CFO can calculate the cost of a data breach or a missed SLA. Few have calculated the cost of one resignation letter arriving on the wrong Tuesday.

The rehiring bill itself is the easy part to model: recruiting fees, signing bonuses, the six-figure total agencies quote for senior engineering talent in a competitive market. Boards ask about it because it shows up on an invoice.

The productivity drag while the system sits half-understood

The harder cost to model is what happens between the departure and the new hire’s full ramp-up. Delivery slows. Bug fixes take longer because nobody’s certain what a change might break elsewhere. Feature work gets deprioritized in favor of keeping the lights on. Projects on a six-week timeline stretch to four months. The new team is competent; they’re just rebuilding understanding from scratch, one production incident at a time.

Nearshore staffing, retention bonuses, and better exit interviews all treat symptoms. Each leaves the actual mechanism untouched: knowledge concentrated in one person with no second copy anywhere.

Why Two Weeks Can’t Move Years of Tacit Knowledge

A handover session captures what a system does. It struggles to capture why. That gap, more than any lack of effort, is the real reason two weeks falls short.

Tacit vs. documented knowledge: what a handover session actually captures

Knowledge researchers split what people know into two buckets: explicit knowledge, the kind you can write down, and tacit knowledge, the kind that lives in judgment and experience. Some call it tacit knowledge. Others call it tribal knowledge. Either term points at the same gap. Analysis from docs.bswen.com puts roughly 90% of organizational knowledge in the tacit category, with only about 10% ever making it into a document, wiki, or code comment. A handover session is built to transfer explicit knowledge: task lists, credentials, a walkthrough of the deployment pipeline. It was never designed to transfer judgment.

Ask a departing engineer why the checkout flow retries a payment call three times instead of once, and you’ll get a story rather than a spec: a vendor outage from eighteen months ago, a support ticket, a Slack thread that no longer exists. That story is the actual knowledge. It’s also exactly what a fourteen-day countdown has no room for. Skip the transfer entirely and what’s left behind is a documentation black hole: a system nobody can safely change without archaeology first.

The math of the notice window: why the timeline itself is the problem

Do the arithmetic honestly. A system built over three years represents roughly 750 working days of accumulated decisions. A two-week notice period offers ten. Even a motivated, well-organized departing employee working eight focused hours a day on nothing but knowledge transfer cannot compress a 75-to-1 ratio into something coherent. And most departing employees spend only a fraction of those ten days on handover anyway. They’re finishing sprints, closing tickets, and, understandably, checking out mentally before their last day arrives.

This is arithmetic at its core, and no offboarding checklist, however thorough, changes the ratio. how tacit knowledge becomes a business continuity risk covers the mechanics of that gap in more depth if you want the fuller picture.

Years of accumulated decisions cannot compress into a ten-day countdown.

Why Offboarding Checklists and Handover Sessions Fall Short

Offboarding checklists are underpowered for the problem they’re being asked to solve.

A good checklist recovers credentials, transfers domain ownership, and documents where the deployment scripts live. That matters. What it reaches is the slice of knowledge that was already explicit and recoverable. The Dreamix team, which studies vendor and team transitions, found that documentation gaps, undocumented dependencies, and lost configuration details create expensive problems months after a transition looks complete on paper. The checklist gets signed off, everyone moves on, and the actual cost shows up later, during an incident nobody can diagnose quickly.

Mentorship programs and pairing sessions run into the same ceiling from a different direction. They shine at onboarding new hires over months. Compressing years of context into ten working days under deadline pressure sits well outside what they can do, especially with the departing employee mentally already at their next job.

So keep the checklist; just treat it as hygiene rather than insurance. Succession planning for a codebase is a different job entirely.

Bus Factor of One: Naming the Real Risk on Your Balance Sheet

Bus factor measures how many people could disappear from a project before it stalls completely. For most internal systems at mid-market companies, that number is one, and almost nobody has put it on a risk register.

Engineers use the term casually, but it maps cleanly onto a concept every CEO already understands: single point of failure. A single point of failure in your data center gets a redundancy plan and a line item in the infrastructure budget. A single point of failure sitting in one engineer’s head usually gets nothing, because it’s invisible until the resignation letter arrives.

The JetBrains Bus Factor Explorer, tracked by LinuxSecurity.com in March 2026, found that even mature, heavily used open-source databases like MySQL and PostgreSQL carry a bus factor of just two. Those are projects with corporate backing, thousands of contributors, and decades of documentation discipline. If a bus factor of two is worth publishing research about at that scale, a bus factor of one on your internal claims-processing system belongs on the board agenda, not buried in a line nobody mentions during the quarterly review.

As Kamila Hankiewicz, Founder and CEO, states: “Your mission as a founder should be to make yourself replaceable, company progress should not depend on you being present. We all know terror corporate stories of backbone architecture written in the ’80s and ’90s in a language nobody uses anymore, so nobody dares to change anything in it.”

That instinct applies just as directly to whoever built your internal order system in 2019. Irreplaceable knowledge concentrated in one head, however talented that person is, represents a structural decision your business made without ever choosing to make it. This kind of single-developer risk rarely gets named out loud until it’s already a crisis, which is exactly why it deserves a name before that happens.

A bus factor of one means one departure is enough to stall the entire system.

The Structural Fix: Knowledge That Lives in Owned Documentation

The fix removes the handover from the critical path entirely, rather than trying to run it better, so no single resignation can take institutional knowledge with it.

What complete documentation includes: UML diagrams, ADRs, API references, test coverage

At Nexa Devs, complete documentation is a standard deliverable on every engagement, not an add-on billed separately or produced only when a client asks. That means UML architecture diagrams showing how the system actually fits together, Architecture Decision Records explaining why specific technical choices were made and what alternatives were rejected, API references built from Swagger and Postman so integrations stay traceable, and test coverage reports showing what’s actually verified versus assumed to work.

An ADR is the piece most internal teams skip, and it’s the one that matters most. A diagram shows you the system’s shape. An ADR shows you the reasoning: why the team picked a message queue over direct calls, what tradeoff they accepted, what would have to change for that decision to stop making sense. That’s the tacit knowledge from earlier in this piece, captured while the reasoning is still fresh instead of reconstructed under deadline pressure after someone’s already gone.

Why day-one, client-owned documentation changes the equation

Timing is the whole point. Documentation produced on day one, as the system is built, captures decisions while they’re being made. Documentation attempted during a two-week exit tries to reconstruct decisions from memory, under pressure, from someone who’s mentally already gone. One approach is a contemporaneous record. The other is an oral history assembled in a hurry.

Ownership matters just as much as timing. We’ve written before about why documentation is the real competitive advantage in outsourced software development, and the same principle holds here: at Nexa, documentation transfers unconditionally to the client, regardless of whether the engagement continues afterward. That single condition changes what the documentation actually is. A file a vendor can revoke access to was never really an asset. A file the company owns outright, one that survives any person’s departure, any vendor relationship ending, any reorganization, is the real thing.

Day-one documentation captures system reasoning before anyone has a reason to leave.

From One Head to an Accountable Partnership

Documentation solves the knowledge problem. On its own, it leaves the accountability problem open, because a document doesn’t answer the phone when something breaks at midnight.

That’s why the structural fix needs a second half: an embedded partner accountable for the system over years, not a vendor who delivers and disappears. Nexa Devs has maintained an embedded engineering relationship with UCLA’s David Geffen School of Medicine for more than 10 years, supporting research and clinical systems in one of the more demanding compliance environments in the country. That kind of tenure reads as more than a testimonial line. It’s evidence that knowledge can accumulate inside a partnership the same way it once accumulated inside a single employee, except the partnership doesn’t resign, retire, or get recruited away by a competitor offering more money.

An SLA-based relationship changes the incentive structure completely. A project vendor gets paid at delivery and has little ongoing reason to keep documentation current. A staff-augmented contractor gets paid by the hour and has every incentive to make themselves indispensable rather than replaceable. An accountable long-term partner gets paid to keep the system healthy and legible for as long as the relationship runs, which puts current documentation squarely in their financial interest.

Ten years at a single institution doesn’t happen by accident. It’s what you get when documentation and accountability are both built into the model from the start, instead of bolted on after the first key-person crisis.

A decade-long partnership accumulates knowledge the same way an employee once did.

Making Knowledge an Owned Asset, Not a Personal Liability

Institutional knowledge is either an asset your company owns or a liability sitting in someone else’s head with an unknown expiration date. There’s no third option worth planning around.

Every company in this piece’s opening scenario made the same unconscious choice: they let critical knowledge accumulate in a person instead of in a system the business controls. Call it a default, the thing that happens when nobody deliberately architects against it. Fixing it starts from a simple refusal: the business’s continuity should not depend on any one person’s decision to stay, however good that person is at their job.

The reframe is simple to state and genuinely hard to execute without a partner built for it: documentation is IP, not paperwork. An ADR explaining a five-year-old architecture decision has real value the day someone needs to change that system. A UML diagram that reflects reality, not the plan from two years ago, has real value the day a new team member needs to get productive fast. Test coverage reports have real value the day someone asks whether a change is safe to ship. None of that value depends on any specific person still being at the company. Researchers who study key-person dependency risk describe exactly this exposure, and pricing it before it becomes a crisis is the whole point.

The two-week handover was never built to save you, whatever anyone hoped it would do. What actually protects a mid-market company gets built in from day one: documentation the business owns outright, and a partner accountable for keeping that knowledge current long after any individual person, including any one Nexa engineer, moves on.

If your business depends on one person’s willingness to stay, that dependency is a risk you haven’t priced yet. Book an architecture assessment and we’ll show you exactly where it’s concentrated.

FAQ

Table of Contents

Sidecar Core Banking: Modernize Without Rip-and-Replace

A mid-market bank’s core system runs the general ledger, the teller platform, and every regulator’s audit trail. Pull it out wrong, and thousands of accounts go dark for a weekend. That fear is exactly why so many banks keep patching a core built in the 1990s instead of touching it.

Sidecar core banking exists to take that fear off the table. Instead of asking whether to rebuild the whole core or swap it in one cutover, it asks a better question: what if the new core ran next to the old one? A sidecar core is a modern banking core deployed in parallel with the legacy system, migrating one product line or customer segment at a time while the old core keeps running everything else. No weekend blackout, and no single date the whole institution has to ride on.

You can’t order sidecar core banking as a Nymbus feature or a Temenos SKU off a price sheet. It’s an engineering discipline: build new core services around what already works, prove each migration segment with production data, and expand only once the last phase held. Rip-and-replace earned its reputation as a career-ending bet, and the sidecar model is what grew up to replace it.

Quick answer: sidecar core banking modernization explained

1. A sidecar core is a modern banking core built and run next to your legacy system, so daily operations stay live while new capability comes online.
2. It’s an engineering discipline, not a packaged product: banks migrate one product line or segment at a time and prove results before scaling further.
3. The strangler-fig approach avoids both failure modes at once: a multi-year rebuild that bets the institution, and permanent lock-in to a single vendor.
4. Staying core-agnostic through the transition means you can still switch vendors later without a rebuild.
5. Complete documentation transfer at every phase means the bank owns every new component, not the vendor.

The Rip-and-Replace Trap: Why Full Core Replacement Bets the Whole Institution

Full core replacement asks a bank to bet three to five years of stability on a single cutover date. Miss that date and you’ve spent millions with nothing shippable to show for it. Hit it and you still have to migrate every account, every integration, and every regulatory report in one irreversible move. This is the incremental-modernization-versus-full-transformation debate playing out with real money on the table, and for a community bank, core conversion risk is existential in a way it simply isn’t for a top-20 institution with a spare balance sheet.

The IBM Institute for Business Value studied banks that attempted full core modernization and found less than half reported meaningful gains on the business benefits they set out to achieve. Worse, 73% said managing costs actually got harder after the attempt, not easier. For a program meant to make costs more predictable, that is the exact opposite of the promised result.

Jouk Pleiter, CEO and founder of Backbase, described pitching incremental transformation on stage and hearing the same reaction for over a decade: “Love the vision. Feels like boiling an ocean.” He was right. Full replacement is boiling an ocean, and mid-market banks don’t have the budget, the bench, or the risk tolerance for a multi-year boil. Every quarter the project runs, the bank is also running its old core in full, doubling maintenance cost and audit surface with zero customer-facing improvement until the very end.

What Sidecar Core Banking Actually Is (And What It Isn’t)

A sidecar core is a new, modern core banking platform that lets you run legacy and modern core in parallel, handling a defined slice of business instead of the whole institution at once. Picture a second engine bolted to the side of the first rather than swapped in for it. The legacy core keeps processing everything it always has: existing accounts, existing statements, existing regulatory reporting. The sidecar core takes on new accounts, a new product line, or a specific customer segment, built on modern, API-first, composable core architecture from day one.

Running the New Core Alongside the Legacy System in Parallel

Money and data move between the two systems through defined integration points, not a single flag-day cutover. If the sidecar handles digital-only checking accounts, every new account for that product opens on the modern core while every existing account keeps running on the legacy platform, until and unless the bank decides to migrate it. Both systems stay live and both stay auditable. The bank controls exactly how much risk it’s carrying at any given moment, because it can stop expanding the sidecar’s scope at any phase without disrupting anything already running.

A Di:,scipline, Not a Product: Why the Sidecar Is an Engineering Approach

Most vendor pitches get this part wrong. They sell the sidecar as a piece of software you install, when it’s really a sequencing discipline: a set of engineering decisions about which components move first, how they integrate with what’s already there, and how each phase gets proven before the next one starts. You can build a sidecar core on almost any modern technology stack. The platform is close to beside the point. What carries the whole thing is the discipline of moving in small, provable, reversible increments instead of one enormous irreversible one.

Diagram showing sidecar core banking architecture running in parallel with a legacy core system.

The Real Cost of Standing Still: What Legacy Cores Quietly Take From You

A legacy core bleeds money quietly. Its share of the budget creeps up year after year, and leadership usually spots the pattern too late to get ahead of it. Accenture found that 70% of the average bank’s IT budget now goes to keeping existing technical debt alive rather than building anything new, according to reporting from The Financial Revolutionist.

The CEO View: Budget Drain and Lost Competitiveness

For the CEO, this shows up as a budget that keeps growing without growing capability. Every dollar spent keeping a 1990s core alive is a dollar that doesn’t go to a new product line, a new market, or the AI-powered service your competitors already shipped last quarter. Boards notice when the technology budget rises every year and the product roadmap doesn’t move, and that’s a harder conversation than any single project failure. For a deeper breakdown of how that budget drain compounds over time, see the hidden tax technical debt is costing you.

The CTO View: No Real-Time Rails, Blocked AI and Integration Work

For the CTO, the cost is architectural. Legacy cores built for nightly batch processing can’t support real-time payments, real-time fraud detection, or the API calls a modern AI agent needs to check a balance or flag an anomaly. Every integration turns into custom middleware bolted onto a system that was never designed to be queried in real time. According to the Open Mainframe Project, the average COBOL programmer maintaining that system is 58 years old, and roughly 10% of that workforce retires every year. The talent that understands the old core is aging out faster than most banks are modernizing around it.

The Strangler-Fig Path: Migrating One Product Line at a Time

Strangler fig modernization works one product line at a time. It starts with whichever line is causing the most operational pain today, often retail deposits or a digital-only account product, and moves that single slice onto the new core first. Commercial lending and treasury management stay put until their turn earns its way up the list.

The pattern takes its name from the vine that grows around a host tree until it can stand on its own, and it works the same way here. The new core wraps around one function of the legacy system, proves it can carry that function reliably under real transaction volume and real audit scrutiny, and only then takes on the next one. A bank might migrate new digital account openings in month one, move existing low-balance checking accounts in month six, and leave commercial lending on the legacy core for another two years, because the risk-to-reward ratio doesn’t justify touching it yet.

Each phase produces its own data: transaction volumes, error rates, customer complaints, regulator questions. That data becomes the business case for the next phase instead of a consultant’s slide deck. If a phase underperforms, the bank stops there. Nothing downstream breaks, because nothing downstream depended on that phase completing.

Strangler-fig migration timeline showing one banking product line moving onto a modern core at a time.

Staying Core-Agnostic: Escaping the Packaged-Vendor Lock-In Trap

Nobody feels locked in on signing day. The trap springs about two years later, once switching costs more than staying, no matter how bad staying has gotten. A core-agnostic strategy is how a sidecar migration avoids repeating that mistake with a new vendor instead of the old one.

Staying core-agnostic during a sidecar migration means choosing integration standards and data formats that don’t need a specific vendor’s proprietary tooling to read or move. It means every new component gets built so it could, in theory, be swapped for a competing product without a rebuild. Most packaged core vendors don’t want that flexibility built in, because flexibility is exactly what erodes their renewal position.

As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another.” A sidecar built around one vendor’s closed stack simply relocates the lock-in. Build it on open standards and documented integration points instead, and the bank gets real negotiating power the next time a renewal comes up, because leaving is actually possible.

Core-agnostic architecture diagram showing open integration standards replacing single-vendor lock-in.

Prove It With Data Before You Scale: The Digital-Brand-First Playbook

PeoplesBank proved a modern core could work without ever touching its main system. It launched ZYNLO, a digital-only brand, on modern infrastructure first, and let the results speak before committing the whole institution. Nymbus, the vendor behind ZYNLO’s platform, reports the digital brand gathered more than $163 million in deposits before PeoplesBank committed to a fuller core transition. That figure comes from vendor marketing material rather than an independent audit, so treat it as directional, not a benchmark to build a business case on.

The pattern matters more than the exact number. Launch the new core on a contained, lower-stakes surface first: a new digital brand, a new product line, a new customer segment, somewhere failure is recoverable and success is measurable. Track the metrics that actually predict readiness for a wider rollout, like transaction error rate, customer onboarding time, integration latency, and support ticket volume. If those numbers hold for two or three quarters under real production load, you have a genuine business case for expanding scope. If they don’t, you’ve contained the damage to one product line instead of the whole bank.

Digital-brand pilot launching on a modern sidecar core before a full bank-wide rollout.

Owning What You Build: Documentation Transfer and Long-Term Independence

Every sidecar migration produces new architecture diagrams, new API references, and new integration logic. One question determines whether this modernization solves the lock-in problem or just relocates it: who owns that documentation when the project ends?

Plenty of vendors and system integrators treat documentation as a professional courtesy, something you get if you ask nicely during the handoff meeting. Complete documentation transfer, meaning UML architecture diagrams, API references, test coverage reports, and sprint records, needs to be a contractual deliverable rather than a favor. Without it, the bank has traded a legacy black box for a modern one with better marketing.

This is where a long-term embedded partner earns its keep. When the same team that built the sidecar phase in year one is still accountable in year three, institutional knowledge doesn’t evaporate the way it does when a project-based vendor delivers, invoices, and moves on to the next client. The documentation exists because the relationship outlasts any single phase, not because a contract clause forced a one-time export.

How to Begin a Sidecar Modernization Without Disrupting Live Operations

Start with an architecture assessment, not a vendor RFP. Map the legacy core’s dependencies, integration points, and data flows before deciding what moves first.

A useful first phase is small enough to fail safely and specific enough to produce real data: a single new product, a single customer segment, a single geography. Set the success criteria before you build anything, not after. Define what “this phase held” actually means in numbers, an acceptable error rate, acceptable latency, acceptable support volume, and give yourself a real decision point instead of quietly expanding scope because the team is already there.

Assign a single accountable owner for the sidecar program, someone who reports both the wins and the failures to the same audience, so the board sees an honest picture instead of a curated one. Mid-market banks that get this right treat the first sidecar phase as a pilot with a hard stop-or-scale decision, not the opening move of an open-ended rebuild. If you’re weighing this against a specific FedNow, real-time payments, or compliance deadline, our core banking modernization roadmap walks through how to sequence that decision.

The rip-and-replace era sold banks on speed. What most institutions actually needed was control. A sidecar core hands that control back, one product line at a time.

Rip-and-replace still sounds decisive in a board meeting. It’s also how banks end up three years and eight figures into a project with nothing live to show for it. If you’re weighing a sidecar approach against your own core’s constraints, schedule an architecture assessment with Nexa Devs and we’ll map the first phase that’s actually worth building.

FAQ

Table of Contents

AI Code Review Bottleneck: Why Teams Ship Slower With AI

Your engineering team rolled out AI coding assistants across the board. Velocity metrics look great in standups. Then you check the pull request queue and it’s three times longer than it was in January. That gap between how fast development feels and how fast code actually ships is the AI code review bottleneck: AI-generated code arrives faster than your reviewers can verify it, so the constraint in your delivery pipeline shifts from writing code to checking it. Slowing AI adoption does nothing about it. The gap closes only when the review system gets redesigned so verification keeps pace with generation. Most teams still have review bolted onto the tail end of a pipeline built for a slower era, and that design is exactly what buckles under AI-scale volume.

The root cause here is systemic, and it won’t yield to another tool. Teams that add more AI coding tools without rebuilding how requirements, tests, and review work together end up with more code and the same review capacity they had a year ago. The organizations that get real throughput gains treat generation and verification as one connected system, built and tested together from the first sprint.

Quick answer: AI code review bottleneck explained

1. AI speeds up writing code, not verifying it, so pull requests outpace reviewer capacity.
2. Review time keeps climbing as AI adoption grows, because merge rates rise faster than review capacity does.
3. Adding reviewers or rushing review doesn’t fix a throughput mismatch. It just moves the backlog.
4. The real fix: build verification into requirements, tests, and review so it scales with generation, not after it.
5. Track delivery flow, not coding speed. That’s where the actual bottleneck shows up.

A pull request queue stacking up faster than reviewers can clear it

The velocity illusion: why AI makes teams feel faster while they ship slower

VentureBeat reports that 43% of AI-generated code changes need manual debugging in production, even after clearing QA and staging. Code passes every gate on the way in and still breaks on the way out. Engineers have a name for that: the velocity illusion.

So which is the real story here, the speed you feel or the speed you ship?

Ask a developer how AI changed their week and most say the same thing: a feature that used to take two days now takes an afternoon. Ask a CTO whether the team shipped three times more verified features last quarter and the answer is almost always no. Both experiences are true at once. They just describe different parts of the pipeline.

The gap between perceived speed and measured delivery

Coding speed and shipping speed used to move together closely enough that nobody bothered to separate them. AI broke that link. A developer using an AI assistant can draft, refactor, and generate boilerplate in a fraction of the previous time. None of that touches the step that actually gates a release: someone with context has to read the diff, understand what changed, and decide whether it’s safe to merge. That step hasn’t gotten faster just because the code arrived quicker.

Where the saved coding time quietly goes

The hours a team saves on drafting have to land somewhere, and where they land is downstream. Reviewers spend more time per pull request reconstructing intent from a diff that came out of a model instead of a colleague’s head. QA spends more time chasing edge cases in code nobody on the team wrote line by line. The net time saved across the full delivery cycle is smaller than the time saved on typing alone, and for some teams it’s negative.

The AI code review bottleneck didn’t disappear, it moved

Every queueing system runs on one rule: if arrivals outpace processing capacity, the queue grows without limit no matter how efficient any single step becomes. Pull request review is living out that rule right now.

Faros AI’s analysis of 10,000 developers found that teams with high AI adoption merge 98% more pull requests while PR review time increases 91%, and average PR size grows 154%. So reviewers absorb a triple hit: more pull requests, bigger ones, and all of it from a source that never explains its own reasoning.

Generation scaled overnight; verification capacity didn’t

Rolling out an AI coding assistant is a one-sprint decision. Growing senior review capacity by the same multiple takes months of hiring, if it happens at all, because most mid-market engineering teams don’t have three extra senior engineers sitting idle waiting for a review queue to appear. Generation capacity scaled overnight while verification capacity stayed flat.

Why review queues explode once AI is writing the code

LinearB’s 2026 Software Engineering Benchmarks Report found agentic AI pull requests wait 5.3 times longer for a reviewer to pick them up, and AI-assisted PRs wait 2.47 times longer, compared with unassisted work. Reviewers work the same as they always have. What changed is arrival rate, which crossed the point where the queue stops draining between sprints and starts carrying over.

A review queue growing week over week as AI-generated pull requests outpace reviewer throughput

Why AI-generated code is harder to review, not easier

Volume alone is manageable. The trouble is code that shows up with no explanation behind it.

A pull request from a colleague usually arrives with context you already share: a Slack thread about the tradeoff, a half-remembered conversation from standup, an assumption about why the retry logic looks the way it does. A pull request generated by an AI assistant shows up as a finished artifact with none of that. The reviewer has to reverse-engineer intent from the diff, with nothing already communicated to lean on.

No intent trail: reviewers reconstruct decisions from a finished diff

Senior reviewers describe the same experience across teams: reading an AI-generated diff takes longer than reading an equivalent human diff, because there’s no design conversation to fall back on. Every unusual choice, an odd exception handler, a nonstandard data structure, has to be evaluated cold rather than confirmed against something the reviewer already knows.

Plausible-but-wrong code and the trust tax it creates

The more experience teams get with AI-generated code, the less they trust it. The Stack Overflow 2025 Developer Survey found trust in AI accuracy has dropped to 29%, even as adoption climbed. Plausible-looking code that fails on a case the model never considered costs more reviewer time to catch than code that’s obviously wrong, because obviously wrong code gets rejected fast. Plausible-but-wrong code gets a slow, careful second look, every time.

Why “review faster” and “just hire more reviewers” don’t fix it

Push reviewers to move faster and defect-escape rates climb. Add reviewers and onboarding overhead eats the gain for months. Neither response touches the actual constraint.

These are the two reflexes almost every CTO reaches for first, and both fail against the same math. Rushing review lowers the bar for what gets caught before merge, and the queue stays exactly as long as it was. Teams that push this lever hardest are the ones who watch production incidents climb even while their review dashboards look green. Hiring more reviewers helps eventually, but a new senior engineer needs months to build the codebase context that makes their judgment worth anything. During that ramp-up, the queue keeps growing anyway.

This mirrors a much older idea from operations management: in any system with a hard constraint, Theory of Constraints thinking says pushing harder on a bottleneck rarely fixes it, redesigning what feeds it does. There’s a third option nobody reaches for first because it means touching the whole pipeline instead of one stage of it: reduce how much verification work review has to do by catching problems earlier, before a diff ever reaches a human reviewer’s queue. Redesigning the system that feeds review takes more work up front than patching the review stage, but it’s the option that actually holds up.

Measure delivery flow, not coding speed

CircleCI’s 2026 State of Software Delivery report, analyzing more than 28 million CI workflow runs across 22,000-plus organizations, found feature-branch throughput up 59% year over year while main-branch throughput fell about 7% and main-branch success rates dropped to 70.8%.

Those three numbers tell the whole story. Feature branches are full of AI-assisted work moving fast. The main branch, the place where code actually becomes a shipped, verified feature, is moving slower and succeeding less often. If your dashboards only track commits opened, PRs raised, or lines generated, you’re measuring the branch that’s lying to you.

The metric that matters is throughput of verified, merged, deployed work: cycle time from first commit to production, and how often a main-branch build actually passes. Frameworks like Google’s DORA metrics exist precisely because coding activity and delivery performance aren’t the same thing, and mid-market teams adopting AI need that distinction now more than enterprise teams did five years ago. A team that generates twice the code but ships the same number of verified features a quarter later has gotten louder, not faster.

The real fix: scale verification with generation across the whole SDLC

Verification has to run through every phase that produces risk. Bolting it onto the end of a single “code review” stage is why the queue keeps growing in the first place.

What that takes is four structural changes, and not one of them is a new tool.

AI-assisted requirements and design that catch ambiguity before code exists

A vague requirement produces a plausible-looking implementation of the wrong thing, and that’s exactly the failure mode reviewers struggle to catch, because the code works, it just solves the wrong problem. Running requirements and system design through AI-assisted analysis before a single line gets written surfaces ambiguity while it’s still cheap to fix. A missing edge case in a spec costs a paragraph to resolve. The same gap discovered in review costs a rewritten pull request.

Tests written alongside code every sprint, not bolted on at the end

When tests get written after the fact, usually under deadline pressure, they tend to confirm what the code already does instead of what it should do. Writing AI-generated unit and integration tests in the same sprint as the code, as a continuous practice rather than a phase-gate, means a reviewer isn’t the only check standing between a plausible bug and production. This is one of the few places automation can absorb real review load instead of adding another tool to the stack. OWASP’s Software Assurance Maturity Model frames this same principle for security specifically: verification built into every phase beats verification bolted onto the last one.

Continuous code review throughout the lifecycle instead of one end-of-line gate

A single review gate at the end of a sprint is where arrival-rate math breaks a team, because every pull request from two weeks of work lands in the queue at once. Reviewing continuously, as work lands rather than as a batch, spreads the same total review load across the sprint instead of concentrating it at the worst possible moment.

Documentation transfer so review isn’t gated on one person’s head

Review capacity is about more than headcount. What really counts is how many people understand the system well enough to review changes to it with confidence. Nexa Devs treats complete documentation, architecture decision records, system design docs, API references, as a standard deliverable rather than an optional extra, specifically because review that depends on one person’s memory doesn’t scale past that person’s calendar. The relationships that have run longest, including a decade-plus engagement with UCLA David Geffen School of Medicine and eight years with TSB, work because institutional knowledge is written down and transferable, not because one engineer never left. For a closer look at how documentation practices change vendor risk, see “why documentation is the real competitive advantage in outsourced engineering”.

For a deeper walkthrough of how these four pieces connect into one delivery system, see “how an AI-augmented SDLC works end to end”.

How requirements, tests, and review connect across every sprint instead of gating at the end

What to automate and what human judgment must still own

Static analysis catches syntax and known vulnerability patterns. It doesn’t catch a wrong assumption about how a payment retries under a network partition. Knowing which is which is what the job really comes down to.

Automate what’s mechanical and repeatable: linting, type checking, security scanning, test coverage thresholds, and policy checks against your own architectural rules. The NIST Secure Software Development Framework lays out this same division for secure development at a policy level: standardize the mechanical checks so human reviewers aren’t burning hours on them. These are exactly the checks reviewers waste time catching manually and exactly the checks a well-configured pipeline never gets tired of running. Every hour a reviewer doesn’t spend catching a missing null check is an hour available for the judgment call that actually needs a human.

Reserve human judgment for architecture fit, business-logic correctness, and risk: does this change interact badly with a system three services away, does the behavior match what the business actually needs, is the blast radius of a bug here acceptable. No automated check can evaluate whether a change is the right change. Only a person with context can make that call, and protecting enough of their time to make it well is the point of redesigning the system in the first place.

Governing the generation ceiling: how much AI code is safe to ship

There’s no universal percentage that tells you how much of a codebase is safe to let AI write. There’s only the ceiling your verification system can actually support.

Teams that treat the generation ceiling as a fixed number, capping AI at some fraction of commits and calling it governance, are solving the wrong variable. The ceiling has far less to do with AI’s capability than with how much verified, reviewed, tested code your pipeline can absorb per sprint without the queue growing. Raise verification capacity and the safe ceiling rises with it. Leave verification flat while you add more AI generation, and all you’ve built is a bigger backlog with better marketing.

As Skylar Roebuck, CTO at Solvd, states: “Traditional modernization tends to over-index on protecting how things work today rather than building for what’s next. AI capability is compounding rapidly, and the real risk for mid-market companies is delay.”

Compliance-heavy environments make this concrete: a healthcare or financial services team can’t treat a fixed generation percentage as a governance answer, because the question an auditor actually asks is whether every change, however it was produced, went through equivalent verification. The NIST AI Risk Management Framework frames governance the same way, as a property of the whole system rather than a cap on any one input. Build generation and verification to scale together, and the ceiling question mostly answers itself: ship as much AI-generated code as your verification pipeline can actually stand behind.

Raising verification capacity is what actually raises the safe AI generation ceiling

The takeaway for engineering leaders

Adding AI to your development process without rebuilding review, testing, and requirements alongside it produces exactly what you’re seeing: faster typing, slower shipping, and a growing sense that something in the pipeline is quietly breaking. Nexa Devs builds AI-assisted requirements analysis, continuous AI-generated testing, ongoing code review, and complete documentation transfer into every engagement, so generation and verification scale together from the first sprint instead of the review stage absorbing the entire cost of AI adoption later.

Ready to see what a review pipeline built for AI-scale generation actually looks like for your team? Schedule an architecture assessment with Nexa Devs and find out where your verification capacity is actually breaking, before your next sprint proves it for you.

FAQ

Table of Contents

SaaS Sprawl: The Real Cost of Mid-Market Tool Overload

Pull up your software subscription report, then count how many of those logins your team actually touched last month. When the first number embarrasses the second, you’re looking at SaaS sprawl: a mid-market company paying for far more software than any team uses, adopted app by app until nobody in the building can name the full list.

The average mid-market company manages 291 SaaS applications, according to SuccessKnocks’ spend-management research, and roughly half of those licenses sit unused month after month. Finance flags the wasted spend first, and that framing understates the damage. What all those redundant apps quietly replaced was one coherent way of working, now split into dozens of disconnected pieces held together by manual handoffs and spreadsheets nobody fully trusts.

For a COO, that gap is more than a procurement nuisance. It’s why your ops team burns hours a week moving data by hand, why a straightforward report takes three people and two afternoons, and why the numbers in Monday’s deck don’t quite match Thursday’s. Trimming a few unused seats fixes none of that. Fixing SaaS sprawl for real means asking why the stack got this tangled in the first place, then building something that fits how your team actually works instead of layering on one more app.

Overlapping software icons across departments illustrating how SaaS sprawl accumulates in mid-market operations

The 291 figure that opened this piece deserves a closer look before we get to the fix.

You’re Licensing 291 Apps and Running Your Operation on a Fraction of Them

Mid-market companies license an average of 291 SaaS applications and use meaningfully fewer than half of them day to day, according to SuccessKnocks’ spend-management research. That gap is too wide to write off as a rounding error. It’s an entire shadow stack your team pays for and rarely opens.

Ask a COO how many tools their organization runs, and you’ll get a number that’s confidently wrong. Finance sees the invoices. IT sees whatever routes through single sign-on. Neither one sees the trial someone in marketing started in February and forgot to cancel, or the project tracker one team adopted because the company-wide tool never fit how they plan their work. Repeat that pattern across every department for a few years, and 291 stops sounding like an outlier.

The uncomfortable part isn’t the count. It’s how few of those apps the operation actually depends on. If your team could lose 150 licenses tomorrow and nobody would notice for a week, the stack was never really designed. It accumulated, one reasonable purchase at a time, until reasonable stopped describing the whole.

How a stack accumulates like that is worth understanding on its own terms, and it points at where the real fix has to land.

What SaaS Sprawl Actually Is (and Why the Usual Definition Misses the Point)

SaaS sprawl is the accumulation of software subscriptions across an organization until nobody, IT included, has a complete or current picture of what’s running, who owns it, or whether it’s still needed. That’s the definition every vendor blog on the subject repeats.

Most explanations stop there and treat sprawl as a governance lapse: too many people with a company card, not enough policy, too little oversight from IT. The framing isn’t wrong, exactly. It just quits one layer too shallow, and quitting there leads straight to a fix that doesn’t hold.

Every app in a sprawling stack was purchased on purpose, by someone solving a real problem right in front of them. Sales needed a way to track deals that the CRM made painful. Ops needed a lightweight tool for vendor onboarding that the ERP module never handled well. Nobody sets out to create sprawl. They buy software because the system they already have doesn’t fit the job in front of them.

That distinction matters because it changes where you go looking for the fix. A governance problem gets solved with a stricter approval policy. A fit problem gets solved by building something that matches how the work actually happens, which is the argument the rest of this piece makes.

Why the Stack Keeps Ballooning: It’s Not Lax Procurement, It’s That No System Fits the Work

The stack didn’t grow because your team ignored the rules. It grew because no single system covered how three different departments needed to work, so each one solved its own gap on its own schedule with its own tool.

Freemium and Trial Entry Make Every New Tool Feel Free

A lot of sprawl starts at zero dollars. Someone signs up for a free tier to solve an immediate problem, no procurement conversation required and no invoice to justify. Three months later the free tier isn’t enough, a card gets added, and a tool nobody formally approved is quietly billing every month.

Multiply that across a workforce with company cards and self-serve signup, and the stack grows one small, individually reasonable decision at a time. Torii’s 2026 SaaS Benchmark research, reported by CIO Dive, found that more than 61% of applications discovered inside organizations were never formally approved by IT, out of an average enterprise footprint of 2,191 applications. Mid-market stacks run smaller, but the same pattern shows up at every scale. Sprawl comes from hundreds of small decisions nobody tracked, never a single big one.

Every Team Buys the Tool That Fits Its Slice, and the Seams Multiply

Marketing needs campaign tracking. Support needs a ticketing system. Finance needs a forecasting tool the ERP handles badly. Each purchase makes sense in isolation, solves a genuine gap, and gets approved because it’s cheap relative to the value it delivers to that one team.

What nobody evaluates is the seam it creates: the manual export from the ticketing tool into the spreadsheet finance uses for revenue forecasting, the copy-paste from the CRM into the project tracker because the two were never built to talk. Individually, every purchase is a rational decision. Collectively, they produce an operation where information moves between systems by hand, and the person doing that moving is the real cost nobody priced into the buying decision.

Diagram showing how department-by-department SaaS purchases create disconnected seams across a mid-market operation

The Real Cost Isn’t the Wasted Licenses

Redundant licenses are the cost your finance team can see on a spreadsheet. The cost they can’t see as easily, fragmented workflows and manual handoffs between systems that don’t talk, is usually bigger and always more expensive to keep ignoring.

Redundant and Unused Spend: The Visible 25-40%

Start with the number everyone quotes. For mid-market companies, 25% to 40% of SaaS spend goes toward tools that are redundant or sitting idle, the highest waste rate of any company size segment, per SuccessKnocks’ analysis of mid-market spend patterns. On a stack running six or seven figures a year in subscriptions, that range is real money.

It’s also the easiest part of the problem to fix, which is exactly why most companies stop there. Cancel the unused seats, fold two overlapping project tools into one, and call the sprawl problem handled. But it isn’t solved. It’s trimmed.

Fragmented Workflows and Manual Handoffs Between Disconnected Tools

Every disconnected pair of tools in your stack needs a human being to bridge the gap between them. Someone exports a report from one system and imports it into another. Someone else checks two dashboards every Monday because neither one shows the whole picture. And somewhere a third person re-keys the same customer record into three places, because the CRM, the billing tool, and the support platform were never built to share it.

None of that shows up as a subscription line item. It shows up as hours, spread across a team that could be doing something the business actually needs instead.

As Jesper van den Bogaard, CEO at Factor Blue, states: “We need to process manufacturing, but the invoice is here, the order data is there, and we’re manually passing information around, with data scattered across different systems.” That description fits far more mid-market operations than the vendors selling into them tend to admit.

Data Scattered Across Systems That Don’t Integrate

When the same customer or transaction lives in five systems that don’t sync, nobody trusts a single version of the truth. Reports pull from whichever system is easiest to export from, not the one that’s most accurate.

So the numbers in Monday’s leadership deck sometimes contradict the numbers in Thursday’s board update, not because anyone made a mistake, but because two people ran two exports from two systems that were never reconciled. This is the cost that never earns a line item. It’s also the one that erodes trust in every operational decision built on top of the data, which for a COO is close to the whole job.

Chart contrasting the visible cost of redundant SaaS licenses against the larger, unmeasured cost of manual handoffs and scattered data

Why a Consolidation Audit Only Trims the Edges

A SaaS audit is worth running. On its own, though, it solves less than it looks like it solves.

The standard playbook is well established: inventory every app, flag the duplicates, cut what nobody logged into last quarter, negotiate better terms on what’s left. Every step is useful. None of it touches why the duplicates existed in the first place.

Six months after a successful audit, the license count usually creeps back up. Not because anyone got careless, but because the underlying condition that produced the sprawl, no single system fitting how the team actually works, never went away. The audit removed the symptoms. The condition that generates them keeps producing new workarounds the moment the old ones get cut.

As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another. Adding vendors and consultants often compounds the problem, bringing in new layers of complexity rather than resolving the old ones.” Ballal was describing legacy infrastructure specifically, but the pattern applies just as cleanly to a stack rebuilt through consolidation alone. Swap five overlapping tools for two slightly less overlapping ones, and you’ve bought time, not a structural fix.

The same logic runs through The hidden tax of accumulated technical debt, where patching a system’s symptoms without touching its root cause produces the same relapse pattern a year later.

The Fix Is One Fitted System, Not One More App

Buying one more platform to unify the others just adds a subscription to an already crowded stack. What actually holds is a system built around your specific workflow, one your team owns outright instead of renting piece by piece.

That’s the difference between adding a vendor and replacing the layer that made vendors necessary in the first place. It’s also the argument most SaaS-sprawl advice skips entirely, because most of that advice comes from companies selling the next subscription.

Scope the System to the Real Workflow, Not the Org Chart

Most software, whether it’s an off-the-shelf SaaS tool or an internally commissioned build, gets scoped around departments: a finance module, a sales module, an ops module. Real work doesn’t move that way. An order travels from sales to fulfillment to finance to support, crossing every department boundary the software was organized around.

Scoping a system to the actual path work takes, rather than to the org chart that approved the budget, is what eliminates the handoffs sprawl created. It’s also why a generic platform struggles here: it was built for a department, not for your specific sequence of steps. The ERP implementation failure pattern runs on the same mismatch, packaged software forcing your workflow to bend around its structure instead of the other way around.

Replace the Workaround Layer Instead of Adding to It

Ask what your team is actually doing in that spreadsheet nobody officially owns, or in the manual weekly export three people dread. The workaround exists because something the team needs isn’t available anywhere in the current stack.

A fitted system replaces that workaround directly. The report that took an afternoon becomes a dashboard that updates itself. The data re-keyed by hand becomes a single record every connected tool reads from. This is the difference between consolidation, which removes duplicate tools, and replacement, which removes the reason the duplicates and the workarounds existed at all.

The market is already moving this direction. Retool’s 2026 Build vs. Buy Report found that 35% of teams have already replaced at least one SaaS tool with a custom build, and 60% had shipped software outside their own IT department’s formal oversight in the past year. Mid-market operations aren’t choosing between SaaS and nothing anymore. They’re choosing between more disconnected subscriptions and one system built to fit.

Comparison showing a fragmented multi-app workflow next to a single fitted system covering the same operational process

Owning the System You Run On

Every SaaS app in your stack comes bundled with someone else’s decisions, documentation you’ll never see, and a renewal date you don’t control. Owning your own system flips all three.

Nexa Devs delivers full documentation on every engagement: architecture diagrams, system design records, API references, and test coverage reports, transferred unconditionally at project close. That’s the antidote to the version of sprawl nobody talks about, which isn’t too many apps so much as too many black boxes you’re paying to run and still can’t fully see inside.

Ownership, in practice, means:

• Complete documentation transferred at delivery, not held as leverage for future change requests
• A system scoped to your actual workflow, not a department template you have to work around
• Ongoing support under an SLA, so evolution doesn’t require finding a new vendor every time priorities shift

None of that eliminates every third-party tool from your stack. Payroll, email, and a handful of specialized platforms will keep making sense to rent. What it eliminates is the default reflex: buying another app every time a workflow doesn’t fit, instead of asking whether the operation deserves a system built for it the first time.

The spreadsheet-run operations that break at scale problem and the SaaS sprawl problem are the same story told from opposite ends. One is too little tooling stretched too far. The other is too much tooling that never quite fit. Both get solved the same way, with a system built around the work rather than the other way around.

Stop Renting Workarounds. Build the System That Fits.

SaaS sprawl isn’t a discipline problem you fix with a stricter approval process. It’s what happens when the tools available never quite matched how your team works, year after year, purchase after purchase.

Nexa Devs builds custom internal systems scoped to your actual operational workflow, backed by AI-augmented delivery across the full development lifecycle and complete documentation your team owns from day one. We support systems we didn’t build too, so a fitted replacement doesn’t require starting from zero.

If your stack has grown past what anyone can fully account for, talk to us about what a system built for your actual workflow would look like. ,Schedule a consultation

FAQ

Body Shop Outsourcing Is Collapsing: What Replaces It

Pull up your last outsourcing invoice. A dozen line items, each billed by the hour, and probably not one of them tied to whether the release actually shipped. Paying for seats instead of results has a name in this industry: body shop outsourcing. It ran as the default IT outsourcing model for two decades, and in 2026 the economics that once made it work quietly stopped adding up.

Agentic AI now generates working code faster than any per-seat billing model ever planned for. Typing speed stopped being the bottleneck. What’s hard to find now is someone who owns whether that code is correct, tested, and still readable eighteen months from now. Body-shop vendors sell the one thing that just got commoditized: raw developer-hours model capacity. Below, I walk through why the model is breaking, what’s taking its place, and how to spot whether your current vendor already crossed the line without telling you.

Quick answer: body shop outsourcing model collapsing

1. Body shop outsourcing means paying for developer hours, not a finished outcome, and it’s losing ground fast in 2026.
2. Agentic AI now generates code faster than any contractor pool, so a markup on headcount no longer buys an advantage.
3. The scarce resource shifted to owned outcomes, verification, and documentation the client actually keeps.
4. Outcome-based and dedicated-delivery models are replacing body shops because one vendor owns the whole result.
5. If nobody can name who’s accountable or where the documentation lives, you’re still renting a body shop.

A side-by-side look at how body shop outsourcing bills for hours while outcome-based delivery bills for a finished result.

What an IT “Body Shop” Really Is (And Why You’re Probably Renting One)

A body shop sells hours, not software: billed by the seat, marked up for the work of finding warm bodies who can code. You rent capacity by the hour, and no one at the vendor carries responsibility for whether the work ships.

The term comes from staffing agencies that treat developers like inventory: place a body, bill the hour, move to the next contract. In IT outsourcing, the body-shop vendor recruits contractors to your spec, invoices for their time, and calls the engagement done. Whether the code works, whether anyone documented it, whether a human can maintain it after the contract ends, none of that lands on the invoice.

Picture a mid-market fintech team that watched three different “senior engineers” cycle through the same feature over four months. Each one relearned the codebase from scratch, and the vendor billed every hour of it, because under a developer-hours model, relearning is billable time like anything else.

This is a different animal from staff augmentation done well, and different again from a Staff augmentation arrangement that keeps real oversight in place. What sets a body shop apart is the thing it never owns: the outcome. The vendor tracks one number, hours logged, and leaves the question of whether the sprint produced value sitting with no one.

The Bill You’re Actually Paying: Churn, No Accountability, and Knowledge That Walks Out the Door

DemandSage’s 2026 research puts it at 20 to 25 percent, the share of outsourcing relationships that fall apart inside the first two years, usually for the same structural reason: nobody owned the result.

The invoice looks cheap until you tally what it leaves out. A body-shop contract prices the hour and nothing else: not the ramp-up when a contractor rotates off mid-sprint, not the rework when the next one reads the ticket differently, not the three weeks your internal team burns reverse-engineering undocumented code after everyone’s gone. A blended delivery arrangement, part staff augmentation and part dedicated ownership, tends to inherit the accountability gaps of both rather than the strengths of either.

No single owner of the outcome

Ask a body-shop vendor who owns it when a release slips, and you’ll get a roster of names where you wanted a single one. Time-and-materials outsourcing can’t assign outcome ownership by design, because the vendor gets paid whether or not the work ships. The Deloitte Global Outsourcing Survey found that 55 percent of failed engagements never tracked benefits against the original goal at all. Nobody watched whether the spend produced value, since nobody’s contract hinged on it.

Ashwin Ballal, CIO at Freshworks, frames the deeper version of this: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another… Adding vendors and consultants often compounds the problem, bringing in new layers of complexity rather than resolving the old ones.” Rotating contractors through a body-shop contract is just the staffing flavor of the same trap.

The knowledge leaves when the contractor does

Contractors billed by the hour have no contractual reason to write anything down. Documentation doesn’t register as billable progress, so it quietly doesn’t happen. When the engagement wraps, or a contractor jumps to a higher-paying gig mid-project, the knowledge of why the system works the way it does walks out with them. Your internal team inherits code it has to relearn from scratch, which is the very expense the outsourcing deal was supposed to spare you.

For a deeper look at how documentation practices separate a real delivery partner from a body shop in disguise, see outsourcing software development documentation.

Verification, not code generation, has become the scarce skill agentic AI can’t replace.

Why Agentic AI Just Broke Body-Shop Economics

VentureBeat’s 2026 survey found that 43 percent of AI-generated code changes still need manual debugging in production, even after clearing QA. Most of the case against body shops sits in that one number: writing code got cheap, and checking it got expensive.

For the CTO: raw coding capacity is no longer the bottleneck; verification is

Agentic AI software development tools now turn out working code faster than any team of hourly contractors. A body shop’s core product is developer-hours spent typing, and that’s precisely the capacity agentic AI commoditized first. The part that stayed expensive is reviewing the output, catching the 43 percent that needs fixing before production, and judging whether a generated solution actually fits the system’s architecture. A body shop was built to sell hours, and judgment like that never came in the package.

For the CEO: a markup on headcount no longer buys an advantage

You used to pay a body shop a markup because sourcing, vetting, and managing contractors was slow and costly. Agentic AI ate into more than the coding; it took a bite out of the sourcing problem too, since fewer raw hands now produce the same volume of code. The companies that already switched can see it on the ledger: moving from shaky time-and-materials outsourcing to dedicated managed services saves an average of 15 percent, according to research from Information Services Group (ISG). Paying a markup on commodity capacity means spending against the wrong scarcity.

What Actually Became Scarce: Owned Outcomes, Verification, and Retained Knowledge

The scarce resource in software delivery has shifted. For years it was raw coding capacity, warm bodies who could turn a spec into working code. Now the shortage sits in three places a body shop was never built to supply: someone who owns the result, someone who verifies it’s correct, and documentation that stays put when the contract ends.

Owned outcomes come down to a single accountable party rather than a rotating cast of contractors, each on the hook only for their own logged hours. Verification is the review and testing muscle that catches what agentic AI gets wrong, the same 43 percent VentureBeat found breaking in production. Retained knowledge is documentation that transfers to the client no matter what happens to the relationship, so the next engineer, yours or the vendor’s, doesn’t open the project at zero.

Gartner projects that more than 40 percent of agentic AI projects will be canceled by 2027, cited via Modus Create’s analysis of the AI ambition gap. Many of those cancellations trace to one root cause: nobody built the verification and knowledge-retention layer the pilot needed to reach production, never mind scale.

All three point to the same requirement: a vendor with a structural incentive to own what happens after the code ships, not only what happens while the meter runs. The industry calls this software delivery ownership, and it runs directly counter to what a developer-hours model was built to provide.

Complete documentation transfer keeps institutional knowledge with the client instead of the vendor.

What’s Replacing the Body Shop: Outcome-Based and Dedicated-Delivery Models

Outcome-based delivery and dedicated-delivery models drop the hourly meter. One bills for the result, the other assigns a single accountable owner to the whole engagement, and both close the accountability gap a body shop structurally can’t.

Outcome-based delivery: the vendor owns the result, not the timesheet

In an outcome-based outsourcing arrangement, payment attaches to a defined deliverable: a working feature, a passing test suite, a system that meets an agreed spec. That flips the vendor’s incentive. Hours spent without shipping the outcome now cost the vendor money instead of earning it. That one change in the incentive structure fixes more body-shop accountability than any volume of vendor management the client can throw at it.

Dedicated delivery: a single owner of day-to-day performance

A dedicated development team puts one lead on the hook for the whole team’s output, in place of a rotating pool of contractors each covering only their own hours. When something breaks, one person owns the fix. Swap a contractor out and the lead runs the transition, so institutional knowledge doesn’t reset with every staffing change. This is the delivery architecture built for engagements measured in years rather than sprints, which happens to be the horizon most mid-market internal systems live on.

For a closer comparison of how dedicated delivery stacks up against staff augmentation on the accountability question specifically, see our breakdown of dedicated team vs. staff augmentation accountability.

How to Tell If Your Vendor Is Still a Body Shop

Pull your last three vendor invoices. If every line item is an hour and nobody signed up to guarantee what those hours produced, you’re renting a body shop no matter what the contract calls it.

Run your current engagement against four questions:

• Who is accountable if the release slips: a named lead, or a list of contractors each covering their own hours?
• Where does the documentation live after this sprint: in your systems, or only in someone’s head?
• Does the vendor’s payment change if the outcome doesn’t ship, or only if the hours aren’t logged?
• Could a new engineer, yours or theirs, pick up this codebase tomorrow without a two-week ramp-up?

Dreamix’s research on vendor transitions found that documentation gaps and undocumented dependencies breed expensive problems months after a handoff wraps, which is exactly what surfaces when the honest answer to that second question is “nowhere.” If two or more of your answers point the wrong way, you’re paying body-shop prices for body-shop accountability, even if the sales deck said “dedicated team.”

A quick four-question test for spotting body-shop billing hiding behind different language.

Choosing a Delivery Model That Owns the Result

Choosing a delivery model comes down to one structural question: who’s accountable when something breaks? Body-shop pricing was never built to answer it.

A body shop can still earn its keep on a short, well-scoped task where the deliverable is small enough that ownership barely registers: patch a script, cover a two-week gap, staff a proof of concept nobody’s betting the business on. Step outside that narrow lane and the model that owns the outcome wins, because agentic AI already wiped out the cost advantage body shops used to trade on. Body shops were never the villains here; they’re just running out of reasons to exist for anything that matters.

Nexa Devs is built around that model: AI-augmented delivery that produces the outcome rather than just the hours, paired with nearshore execution in U.S. time zones and complete documentation transfer that’s unconditionally yours when the engagement ends, whether or not you renew. The system stays understandable after the contract closes, because the knowledge doesn’t leave with a rotating contractor. That’s what a structural answer looks like for a model already running out of runway.

If you want a second opinion on whether your current vendor is still running a body shop under a different name, talk to our team about what an outcome-owning engagement actually looks like.

FAQ

EMR Lab Integration: Fixing the Gap Without a Rebuild

A hospital’s EMR and its lab system are supposed to talk to each other without help: an order goes out, a result comes back, and nobody touches it in between. EMR lab integration is the technical work that makes that happen, connecting your EMR to your LIS, radiology system, and referral network through HL7 or FHIR interfaces so data moves without a human retyping it. When that connection breaks, or was never built cleanly in the first place, the workflow doesn’t stop. It moves to your staff, one keystroke at a time.

This plays out every day wherever LIS EHR integration happens by hand: rekeyed results, duplicate patient records, and manual bridges that hold together right up until volume climbs past what they can carry. Below, we walk through why the gap exists, what it costs a hospital operationally, and how mid-market providers close it with incremental integration middleware rather than a full EMR replacement.

A clinical staff member manually re-entering lab results because the EMR and LIS have no clean data connection.

When Your EMR Can’t Talk to Your Lab System, the Workflow Runs on People

A lab tech at a 200-bed regional hospital finishes a results batch at 4:45 pm. The LIS has no clean feed into the EMR, so she opens both screens and retypes fifteen results by hand before her shift ends.

Multiply that by every shift, every department, and every system that was never designed to exchange data with the one beside it, and you start to see the real shape of the integration gap. Nobody filed it as a missing feature or put it in a budget. It just quietly turned into a permanent staffing cost.

Rekeying lab results by hand between systems

Manual rekeying isn’t a minor inconvenience. Every retyped value is a chance for a transposed digit, a missed decimal, a result attached to the wrong encounter. A potassium level of 6.5 entered as 5.6 doesn’t get flagged by either system, because neither system knows the number came from a human instead of an interface. The clinician downstream trusts the chart. The chart is only as accurate as the last person who typed into it.

How duplicate patient records multiply when systems don’t reconcile

When the EMR and LIS can’t reconcile patient identity automatically, staff build workarounds: a new record here, a manually matched chart there. CertifyHealth’s analysis of ONC data found that only 43% of hospitals report routine engagement across all four interoperability domains: send, find, receive, and integrate. The other 57% are living with some version of this gap, and duplicate records are one of its most visible symptoms.

What happens to the patient record when two systems disagree about who the patient is? Usually, both versions survive. A lab result posts to the wrong MRN, a medication history splits across two charts, and the clinician making a decision at 2 am is working from an incomplete picture without knowing it’s incomplete. That’s not an efficiency problem. That’s a patient-safety problem.

The Hidden Operational Cost: Manual Bridges That Break Under Load

Manual bridges hold up fine on a slow Tuesday. Add a flu surge, a new referring clinic, or a lab acquisition, and the same workaround buckles within days, because a human process doesn’t scale the way an interface does.

Where the workarounds fail during volume spikes

The failure pattern is predictable. Volume climbs, the same two or three staff members who know the manual process are already at capacity, and results start queuing. A result that should post in seconds sits in someone’s inbox for forty minutes, then two hours, then it’s the end of shift and nobody’s sure what’s been transcribed and what hasn’t.

Aalpha’s 2025 research, citing Gartner, puts the figure at up to 75% of hospital IT budgets consumed by maintaining legacy systems rather than fixing the workflow gaps sitting on top of them. That number isn’t abstract for a COO staring at a stack of overtime approvals during a bad flu season.

Rework, delayed results, and staff burnout as measurable operational drag

Every rekeyed result that turns out wrong needs to be caught, traced, and corrected, which means someone re-does the work a second time. Delayed results delay clinical decisions. And the staff holding the bridge together, the ones who know which spreadsheet tracks what and which fax needs a follow-up call, are the same staff a COO can’t afford to lose. anchor text “hidden cost of running critical systems on manual workarounds”

None of this shows up on a single line item. It shows up as unplanned overtime, as a nurse manager pulled off the floor to reconcile a chart, as the quiet turnover of the two people who understood the workaround well enough to keep it running.

A simplified view of an interface engine routing lab orders and results between the EMR, LIS, and radiology systems.

Why the Systems Don’t Talk: HL7, FHIR, and the Interface Layer Underneath

HL7 v2 is a decades-old messaging standard built around pipe-delimited text segments rather than a modern API. FHIR R4 is newer, built on REST and JSON. Most hospitals run both side by side, which is completely normal.

HL7 v2 messaging vs. FHIR R4 APIs

HL7 v2 still carries most day-to-day electronic lab ordering and results traffic, and it works well enough, as long as every endpoint implements the same optional fields the same way. In practice, endpoints rarely do. FHIR R4 adds a standardized, resource-based API layer on top, useful for real-time queries, patient portals, and newer applications that were never built to parse pipe-delimited segments.

Invene’s research, citing HIMSS data, found that 67% of CIOs name interoperability as their biggest digital transformation barrier. The regulatory direction backs that up: the CMS-0057-F final rule requires impacted payers to implement four FHIR APIs, covering patient access, provider access, payer-to-payer exchange, and prior authorization, by January 1, 2027. So FHIR has stopped being a future consideration. Every serious health IT investment is already heading in its direction.

Point-to-point interfaces vs. a middleware/interface-engine approach

Point-to-point interfaces connect exactly two systems, one custom build at a time. Add a fourth lab partner or a new referral network, and you’re commissioning another custom interface, tested and maintained separately from every other one you already have. An HL7 interface engine sits in the middle instead, translating once and routing to every connected system from a single, maintainable layer.

Where legacy interfaces fall short of current interoperability requirements

Interfaces built a decade ago were often scoped narrowly: this lab, this EMR, this one message type. They weren’t built to add a fifth radiology partner or expose data through a modern API, so every new connection becomes a bespoke project instead of a configuration change. That architecture problem is what shows up downstream as overtime, rekeying, and burnout.

What Closing the Loop Actually Buys You: Orders and Results That Flow

A closed order-to-result loop means an order placed in the EMR reaches the LIS in seconds, and the result posts back to the right chart without anyone touching a keyboard in between. Every hospital should start from that baseline. It is not a premium feature a vendor gets to upsell later.

Closing the loop buys three things a COO and a CTO both care about, for different reasons. Fewer manual steps means fewer chances for a transcription error to reach a clinician. Faster turnaround means a result that matters at 2 am actually shows up at 2 am, not during morning rounds. And clean, structured clinical data exchange means the reporting your leadership team relies on reflects what actually happened in the systems, rather than what someone remembered to type in after the fact. That is clinical workflow integration doing its job quietly in the background.

None of this requires exotic technology. The Office of the National Coordinator for Health IT has published a working definition of interoperability for over a decade: the ability of systems to exchange and use information without special effort on the part of the user. “Without special effort” is the entire point. If your staff is putting in special effort every shift, the loop isn’t closed yet, no matter what your EMR vendor’s marketing page says.

Incremental Integration Middleware vs. Ripping Out the EMR

Rip-and-replace is the wrong first move for almost every mid-market provider chasing a lab integration fix. It’s also the most expensive one, and it solves a problem you don’t actually have.

Connecting LIS, radiology, and referral systems without replacing the core EMR

Your EMR usually isn’t the broken part. The connections around it are. A phased healthcare API middleware build, an interface engine or FHIR facade layered over your existing EMR, connects the LIS, radiology, and referral systems you already depend on without touching the system your clinical staff has spent a decade learning to trust.

As Ashwin Ballal, CIO at Freshworks, states: “Legacy systems have become so complex that companies are increasingly turning to third-party vendors and consultants for help, but the problem is that, more often than not, organizations are trading one subpar legacy system for another.” A full EMR replacement carries exactly that risk, at a much higher price and on a much longer timeline.

A phased rollout that de-risks the change

Hypertrends’ 2026 research puts a full EHR replacement at a mid-size health system between $50 million and $200 million, spanning three to five years. The same research found that big-bang modernization projects, the ones that try to replace everything at once, fail more than 70% of the time. A phased rollout does the opposite: connect the highest-friction system first, usually the lab, prove the pattern works, then extend it to radiology and referral networks on a timeline that doesn’t require betting the department’s budget on a single go-live date.

A phased middleware rollout connecting the EMR to lab, radiology, and referral systems one interface at a time.

Getting It Right: Security, Compliance, and Documentation You Own

PHI moves through every interface you build. That makes security and compliance design requirements you settle at the first architecture diagram, long before anyone gets to a post-launch checklist.

Protecting PHI and staying compliant during and after integration

Every connection point, EMR to LIS, LIS to a reference lab, referral system to a specialist’s portal, is a place PHI can leak if access controls, encryption, and audit logging aren’t built in from the start. According to ANI Solutions, information blocking penalties under ONC enforcement can reach up to $1 million per violation for health IT developers. A penalty that size is a strong argument for building the integration correctly the first time, with security reviewed at every interface as you go rather than bolted on once everything is already live.

Why owning the interface documentation matters for a mid-market provider

Ask who currently understands your existing interfaces well enough to modify one without breaking three others. If the honest answer is one person, or one vendor who won’t hand over specifications, you already have a second, quieter integration gap: a knowledge gap. Complete interface documentation, message specs, mapping logic, and architecture diagrams, transferred to and owned by your organization, closes that gap permanently. anchor text “how EHR interoperability compliance requirements reshape your integration roadmap” It also means the next vendor, or the next hire, doesn’t start from zero.

A COO and CTO reviewing complete interface documentation that stays with the organization instead of a vendor’s files.

Choosing an Integration Approach That Fits a Mid-Market Provider

Most mid-market providers don’t need a platform vendor selling a new EMR for what is really a hospital system integration problem. They need a partner who can map their specific EMR, LIS, and referral network, then build the interfaces in a sequence that doesn’t stall clinical operations.

Three things separate an integration partner worth hiring from one that isn’t. First, a phased plan that connects your highest-friction system first, before it promises anything about the rest. Second, documentation you own outright at every milestone, handed over as you go and never held back until project close. Third, a real track record in environments where a mistake carries clinical consequences, the kind of work an e-commerce shop relabeled for healthcare has never actually done.

Nexa Devs has maintained an embedded engineering relationship with UCLA’s David Geffen School of Medicine for more than ten years, building and supporting systems in a regulated, high-stakes clinical environment where documentation and reliability aren’t optional. That kind of track record is the credibility anchor mid-market providers should be asking every integration vendor to match. If a firm can operate inside an academic medical center’s compliance requirements for a decade, a mid-market hospital’s LIS and referral network is a problem they’ve already solved a version of.

Nearshore, AI-augmented delivery, applied to the analysis, build, and testing phases of an integration project, means that phased middleware rollout can move faster than a traditional staffing model without cutting corners on documentation or testing coverage. The goal isn’t a faster rip-and-replace. It’s a shorter path from “our systems don’t talk to each other” to an integration layer that runs quietly in the background, the way it should have from the start.

Ready to connect your EMR to the lab, radiology, and referral systems it should already be talking to, without a rip-and-replace? Talk to Nexa Devs about building your integration roadmap. We build the HL7/FHIR middleware layer, with documentation you own, in environments where the stakes are real.

FAQ