PITT OHIO

The client

PITT OHIO is a regional less-than-truckload (LTL) carrier that has been moving freight since 1979. Out of a network of terminals across the Mid-Atlantic and Midwest, the company handles LTL and truckload freight along with supply chain services like expedited shipping, freeze protection, warehousing, and container transloading. For a carrier, the website is not a brochure — it is where customers rate shipments, schedule pickups, trace freight, and pull account data. That online toolset is a working part of daily operations, so any change to it had to respect a large body of existing back-end systems and the customers who depend on them.

The problem

When I came in, the public site and the customer portal were running on an aging classic ASP codebase. It was difficult to extend, hard to maintain, and increasingly out of step with the .NET services the business had built up behind it. PITT OHIO wanted to move to a modern, maintainable platform without throwing away the back-end investment — the shipping, account, and user systems that already ran the business — and without disrupting the online tools customers relied on every day.

The approach

I designed the replacement architecture around ASP.NET MVC 5 with Orchard CMS 1.9 as the content and application layer, integrated with the existing back-end services rather than rebuilt on top of them. Orchard gave the marketing and content teams a CMS they could actually work in, while its module system gave me a clean way to bring the customer-facing tools forward as first-class .NET components instead of one-off scripts.

The guiding principle was integration over replacement. The authoritative data — users, shipments, accounts — stayed where it lived. My job was to put a modern, testable, maintainable layer in front of it and to migrate the tooling onto that layer piece by piece.

What I built

I started with a proof of concept: a Shipment Trace tool implemented as a custom Orchard module. It validated the pattern — a customer-facing operational tool living cleanly inside Orchard and talking to the existing services — before we committed to converting the rest.

Authentication was the linchpin. Rather than stand up a parallel identity system, I fully implemented a Membership Service provider for Orchard that authenticated users against PITT OHIO’s existing user database. That let me map approved services directly to Orchard roles and permissions, so a customer’s real entitlements drove what they could see and do on the site.

To move data between the front end and the back-end systems, I built RESTful services for shipping and account data using Web API 2. Security and logging were handled through ActionFilter-based cross-cutting concerns, with custom ExceptionHandler classes so failures were caught and surfaced consistently rather than leaking through.

With the pattern, the auth model, and the service layer in place, I converted 30 of the client’s classic ASP online tools into custom Orchard MVC modules and widgets — retiring the legacy codebase tool by tool and bringing each one onto the new, maintainable platform.

Continuous integration

Because the solution deployed across multiple environments — a web host for Orchard and separate application servers for the services — I set up a Jenkins build server with continuous integration covering both the custom Orchard CMS project and the services project, with cross-server deployment. I customized the CI build to use Git, MSBuild, VSTest, Slack notifications, and Visual Studio Online (VSTS) integration, so builds, tests, and deployments ran automatically and the team stayed informed. Unit tests were written with NUnit and Moq and enforced in the pipeline.

The result

PITT OHIO moved off a hard-to-maintain classic ASP stack and onto a modern .NET/Orchard architecture that its content team could manage and its developers could extend — without abandoning the back-end services that run the business, and without breaking the customer tools people use every day. The migration was structured so the legacy site could be retired incrementally: prove the pattern, solve authentication once, build the service layer, then convert the tools one at a time behind a CI pipeline that made each release repeatable.

Stack

ASP.NET MVC 5 · Orchard CMS 1.9 · Web API 2 · NHibernate · Autofac · AutoMapper · SQL Server 2012 · jQuery · NUnit · Moq · Jenkins (Git, MSBuild, VSTest, Slack, VSTS)