SrinSoft makes the old world talk to the new

A bill of lading is an unglamorous place to look for a software company’s purpose. Yet SrinSoft’s freight case study begins there: handwritten information, paper documents, a driver applying matching labels to a shipment and its paperwork. Data entered the system late. Errors had room to multiply. The expensive computer could keep running while the information feeding it arrived slowly, one human handoff at a time.

That is a useful introduction to this company. SrinSoft sells expertise for situations where replacing a screen will not fix the work behind it. Its territory includes legacy applications, middleware, testing, engineering design and the awkward journey between systems. The common question is practical: how much useful work gets lost at the boundary?

A business built around the handoff

SrinSoft dates its beginning to 2005, with three people, an Ohio headquarters and a development center in Chennai. It established an IBM i center of excellence and engineering design services the following year. Those two tracks still explain an unusually broad portfolio. One deals with business transactions; the other with the digital descriptions of things people intend to build.

Founder Ram Hari had worked on AS/400 applications and later rose through the technology organization at restaurant-supply business Wasserstrom. In his 2022 interview with IT Jungle, he described starting SrinSoft alongside that job. Wasserstrom subsequently became a customer, seeking offshore delivery capacity. The first substantial lesson was close at hand: a buyer wanted people who understood its existing operations.

Hari also described a staffing constraint. New graduates knew newer languages but needed instruction in IBM i and Db2. SrinSoft trained them. That makes the company’s learning culture commercially relevant: customers need someone available to understand the system after the people who originally wrote it move on.

The system works. The work gets harder.

“Because even if it isn’t broken, it’s getting harder to run.”SrinSoft’s explanation of why IBM i applications need modernization

IBM i is the operating environment descended from the AS/400 world. Companies can have years of business rules embedded in its applications. SrinSoft offers development, maintenance, integration and modernization around that installed base. Its proposal includes converting older fixed-format RPG code, improving databases and bringing development into version-controlled, tested workflows.

The sequence matters. SrinSoft’s published modernization approach starts by examining applications for redundant code and anomalies. It then establishes version control and regression testing before modernizing code, database and interface. The implied lesson for a buyer is sensible: learn what the application does, build a way to detect breakage, then change it.

Integration and quality engineering widen the assignment. SrinSoft builds API and middleware connections, supports business process management and offers DevOps services. Its testing practice covers customized enterprise environments throughout the development cycle. A company buying this work can therefore address the connection, the release process and the checks that keep a customization from quietly breaking something else.

What the freight cases reveal

The shipping-document example is revealing because its initial problem sits outside the application. Handwriting, manual labels and delayed entry are workflow constraints. SrinSoft describes a journey-centric application as its response. The broader lesson is to trace information from its point of creation, rather than beginning with a shopping list of replacement technology.

Another published transportation case describes a carrier that needed to double its IT department, add project managers, analysts, IBM i specialists and testers, and establish a project management office. It also faced limited local access to relevant experience. The case headline reports a 35% reduction in critical incidents. That is a company-reported result for one engagement, not a forecast for another buyer.

Put the cases together and the market position becomes clearer. SrinSoft serves organizations that already have consequential systems and need specialist capacity around them. Its buyers span logistics, manufacturing, insurance, retail and distribution. The company reports more than 250 clients. This is a services relationship built around an installed business, with its accumulated rules and exceptions.

Then Autodesk bought part of the bridge

The engineering side gives the same idea a different shape. SrinSoft Engineering offers BIM modeling, scan-to-BIM, design work and automation. BIMDeX developed ways to exchange engineering models between applications. Moving a model usefully means retaining more than its visible outline; the receiving team needs information it can continue working with.

In September 2025, Autodesk announced beta access to BIMDeX Data Exchange workflows, including connections involving Plant 3D, Revit, Tekla, Inventor and Civil 3D. Its announcement included a Siemens Energy user explaining that moving data efficiently had improved the team’s BIM workflow. Here was a named customer and a concrete task, beyond the usual promise of smoother collaboration.

On September 30, 2026, Autodesk confirmed it had completed the acquisition of selected BIMDeX technology assets and intellectual property. A subset of the team joined Autodesk. Existing customer contracts and support stayed with SrinSoft. The transaction gives the interoperability work a particular significance: a platform owner chose to bring some of that technology inside its own organization.

Buy the assignment you actually have

SrinSoft offers four commercial models: fixed price, time and materials, dedicated resources and managed services. Fixed-price work has an agreed scope and milestone payments; scope changes trigger change management. Time and materials accommodates evolving requirements. Dedicated teams provide specialist capacity, while managed services hand over responsibility for an ongoing service.

Those choices expose the conditions for a useful engagement. A stable specification suits a fixed commitment. An uncertain legacy application needs investigation and room to adjust. A small business seeking an inexpensive, ready-made app may have little reason to commission this kind of delivery team. And a modernization project cannot decide its priorities merely by choosing a supplier.

For a prospective customer, the first task is to identify one troublesome handoff and measure it: re-entry, waiting, failed releases or model rework. Preserve the rules that matter. Test a change against the real workflow. The humble freight document offers a good starting point. Follow it closely enough, and the technology decision becomes much easier to make.