Hard-to-test 3 Tier Architecture
Firstly and unfortunately, there isn't an immediate plan to replace the entity specific ADO.NET with an ORM.


That's fine.

This is more questionable:


private int GetSqlOutputParam() { return 1; }



It would be much clearer to declare this as a descriptively named constant near the top of the class (being class-level scoped):

private const int defaultEntityId = 1;




But that's far from being what's making that code hard to test.


  I would like to start by making the code a little more testable by
  removing all persistence calls from the business logic layer, or
  separating the actual logic away from these calls while keeping them
  in the same layer. Instead of update() and read() littered throughout
  those manager classes, the object would be passed around as much as
  needed.


A class such as an OrderHeader exists to hold data. Nothing less, but also and more importantly nothing more. It's a Plain Old CLR Object, a POCO. You hit the nail on the head, that's exactly what you need to do. Move the ADO.NET code into its own class.

As much as I dislike this pattern when it's used on top of Entity Framework, if I had to refactor some ADO.NET code into its own class, I'd probably write something like a repository:


  
  
  This blog post (click the diagram) explains how dependency inversion enables testing.
  
  (I am not the author of the blog this link points to, it's pure coincidence that this guy's name is Mat. I'm not this Mat's Mug.)