The systems are fine. The space between them is the problem.
Migrations that were quoted as replacements, interfaces that were meant to be temporary, and a report nobody can produce because the data lives in three places with three definitions of the same field.
Bought by any agency running more than one system of record.
Found Nineteen dependencies nobody had written down, including two reports the finance office runs monthly. Found before the migration, not during.
What the work produces
- Databases moved without a rewrite
- Migration and modernization of what you have, including PostgreSQL and other enterprise databases, rather than a replacement nobody can fund.
- Interfaces that are documented
- System-to-system connections somebody else can maintain, written down, with the failure modes named.
- One definition of the number
- Reporting assembled from the systems of record so the figure in the board packet and the figure in the department agree.
- Legacy replaced in stages
- The old system stays up while the new one takes over one function at a time, because a cutover weekend is how these fail.
Also in this category: Database migration and modernizationPostgreSQL and enterprise database supportSystem-to-system interfacesReporting and data warehousingLegacy system replacement, in stages
Limits
What we will not do.
Stated before a solicitation rather than after an award, because finding this out late is expensive for both of us.
- We do not do staff augmentation. If what you need is bodies at an hourly rate, we are the wrong shape and there are firms that do it well.
- We will not migrate a database without reading what depends on it first. That reading is most of the work and it is where the quote comes from.
- We do not run your infrastructure indefinitely. Support is available and optional, and it is not a condition of the build.
Questions a buyer asks
Do you support PostgreSQL specifically?
Yes — migration to it, from it, and support of existing instances including version upgrades, performance work and high availability. It is one of the most common things we are asked about.
Can you take over a system somebody else built?
Usually, and the first step is a paid read of what is actually there. Inheriting a system without that is how the second vendor becomes the one blamed for the first vendor’s decisions.
What if the original vendor is gone?
That is a common starting point. What matters is whether the data is reachable and the behavior is observable, and both usually are even when the source is not.
How do you contract with a public entity?
Through whatever vehicle the entity uses: direct award under the bid threshold, competitive solicitation, an interlocal or cooperative contract, or as a subcontractor to a prime. We will tell you which we are eligible for before you spend evaluation time on us.
Where does the software run?
In the entity’s own cloud accounts, under the entity’s own contracts. We are given scoped access during the build and it is revoked at handover. That keeps the data inside your perimeter and means nothing depends on us continuing to exist.
Who owns the code?
You do. Source is delivered to your repository under a license permitting unrestricted use, modification and resale, with documentation written for whoever inherits it. There are no seat licenses and nothing switches off if the relationship ends.
What about accessibility?
Anything public-facing is built to WCAG 2.1 AA and tested with a keyboard and a screen reader before handover, not after a complaint. Say in the solicitation if you need a VPAT and we will produce one.
What about records retention and open records?
Anything we build that holds public records is built assuming those records will be requested. That means exportable, searchable, and able to produce a defensible set for a request — designed in rather than added later.
School district systems Permitting and licensing Records and document automation