CompanyGraph
Cognizant Technology Solutions Corporation
CTSH · United States
Converts old COBOL bank and hospital software into modern cloud systems without breaking the transaction logic regulators require.
Cognizant migrates the COBOL mainframe systems that run Fortune 500 banks and healthcare insurers onto cloud infrastructure, using a proprietary translation engine that converts 1970s transaction logic into Java while preserving the exact rounding rules and branching sequences that regulatory audits require. Because the engine is embedded directly into a client's legacy codebase once migration testing begins, swapping it out for a competitor's tools would force the client to restart a multi-year regulatory requalification cycle from scratch — a cost no bank will accept mid-project, which turns each active engagement into a durable lock. The engine's reliability depends on thirty years of edge cases accumulated across successive Fortune 500 migrations, and those edge cases are only discoverable by running real migrations and diagnosing the failures, so a new entrant cannot reconstruct the library by hiring engineers or buying similar software. The whole chain depends on Indian architects who understand both mainframe logic and modern microservices being physically present at client data centers, and if H-1B and L-1 visa approvals tighten, those engineers cannot reach the US sites where legacy systems must be accessed in person — cutting the bridge between the offshore delivery centers and the clients they serve.
How does this company make money?
The company earns most of its revenue through multi-year fixed-price contracts for full system modernization projects, which range from $50 million to $500 million each. Once a migration is complete, it collects ongoing monthly fees to manage the cloud infrastructure and maintain the applications it migrated.
What makes this company hard to replace?
Switching vendors mid-project would require a complete restart using new tooling, because the translation engine is embedded directly into the client's legacy codebase and a different vendor's tools cannot pick up where it left off. For banking and claims systems, regulatory requalification cycles after any vendor change take multiple years — no client will absorb that delay once a live project is underway. The Indian delivery teams also accumulate deep knowledge of each client's specific business logic over the course of a project, and a new vendor would have to relearn all of it from nothing.
What limits this company?
The company needs senior architects who understand both 1970s mainframe systems and modern cloud design. That combination takes decades of hands-on work to develop and cannot be taught in a training program. Worse, those architects must visit client data centers in person, because the legacy systems cannot be accessed remotely. There is no shortcut to getting more of these people, so the number of projects the company can run at once is capped by how many of those architects exist.
What does this company depend on?
The company cannot operate without H-1B and L-1 visa allocations that allow Indian engineers to work on-site at US client locations. It also depends on Google Cloud Platform partnerships for modernization tooling, licenses for the COBOL-to-Java automated translation software, leases on its Chennai and Pune delivery centers, and physical access to mainframe systems inside client data centers.
Who depends on this company?
JPMorgan Chase and Bank of America rely on the company for core banking modernization — if those projects stop mid-stream, transaction processing systems could fail. Aetna and Humana use it for claims processing migrations — a stalled project would force those systems back to manual workflows. Target depends on it for ERP modernization work that keeps inventory management running in real time; abandoning those projects would cost that capability.
How does this company scale?
Once the COBOL-to-cloud translation methods and offshore project management processes are built, they can be applied to new clients without rebuilding from scratch. That part scales. What does not scale is the supply of senior architects who understand both legacy mainframe logic and modern microservices design — that knowledge takes decades to develop, cannot be trained quickly, and must be physically present at client sites. So each new project demands more of the one resource that cannot be grown on demand.
What external forces can significantly affect this company?
US immigration policy is the sharpest external risk: if H-1B and L-1 visa approvals tighten, Indian engineers cannot reach the US client sites where mainframe systems must be accessed in person. Rupee appreciation against the dollar squeezes margins, because contracts are billed in US dollars but most of the work is paid for in Indian rupees — when the rupee strengthens, the same dollar revenue buys less delivery capacity. Federal Reserve banking regulations that require US data residency also constrain which AWS regions can be used, narrowing the architecture options available during migrations.
Where is this company structurally vulnerable?
If the translation engine contains a systematic bug — say, a single mishandled rounding rule — it would silently replicate that error across every client running the same engine version. Multiple banking or claims systems could produce wrong transaction results at the same time. Fixing it would require emergency patches tested across dozens of different mainframe setups. That kind of failure would destroy client trust in the engine's core promise — that the translated code behaves identically to the original — and once that promise is broken, the reason no client ever replaces the company mid-project disappears.