FUNCUAN, from paper and a legacy system to a complete clinical platform in 7 weeks

What was the problem?

FUNCUAN runs five operations in one: mass sterilization campaigns in neighborhoods (hundreds of animals a day), a clinical center with hospitalization, patrols rescuing animals in the field, a call center taking ~30 calls a day, and an adoption program. All of it under a public contract that requires 14 official forms depending on the type of care, filled out, signed, and archived.

The operation lived in two worlds that never talked to each other: a legacy .NET system holding years of accumulated history, and paper. Official forms were filled out by hand and archived in physical folders. Field patrols had no guaranteed connectivity, so their records arrived hours or days later, transcribed by hand. Reports for the city government were assembled manually every period, cross-referencing sources that didn't match. And years of clinical histories, photos, X-rays, and signed consent forms lived in a system nobody could maintain anymore.

What did we consider before building?

We evaluated commercial veterinary clinic software first. None of it fit: it's designed for private practices with individual appointments, not for a public operation with mass sterilization campaigns, field patrols with no signal, 7 distinct user roles, and specific official forms required by a municipal contract. Forcing FUNCUAN's operation into a generic SaaS would have meant keeping half the work on paper.

A second constraint defined the project: the foundation could not lose its history. Over 100,000 registered animals, tens of thousands of documented sterilizations, X-rays, signed consent forms. Any new system had to launch with all of that data already in it, not start from scratch. That turned the data migration into a project as important as the software itself.

We didn't write code the first week: we spent it inside the operation, shadowing the team and collecting the 14 official forms the system had to produce. We designed the software backwards from the documents the foundation is legally required to deliver, not the other way around.

How did we design the solution?

A single web platform with modules covering the entire operation:

• Tablet-first clinical records, consultations, emergencies, follow-ups, and campaign encounters are registered on tablets directly at the point of care, with PIN-based authentication for clinical staff and on-screen signature capture (guardian and staff).
• Mass sterilization campaigns, batch registration optimized for the real pace of a campaign day: hundreds of animals in a day, without navigating profile by profile.
• Hospitalization, areas, cages, transfers, evolution notes, and a visual AM/PM medication grid for support staff.
• 100% offline field patrols, a PWA that works with no signal at all: captures photos (a 3-photo protocol per incident), GPS, and rescue data, then syncs automatically when connectivity returns, without duplicating records.
• Call center, call registry and categorization, patrol assignment, and follow-up.
• Adoptions and triage, adoption request workflow and urgency classification on arrival.
• 14 official forms as PDFs, every document that used to be filled out by hand is now generated automatically from system data with digital signatures stamped in, matching the exact format the contract requires.
• Reports for the city government, periodic reports (sterilizations, emergencies, adoptions, census by neighborhood) come out as Excel and PDF in one click, from the same operational data.
• Universal audit trail, every mutation in the system is logged automatically: who changed what, when, and from where. Indispensable in a publicly funded operation.

All of it with 7 user roles (administration, coordination, reception, veterinarians, assistants, patrols, and inventory), each seeing exactly what their job requires.

How did we migrate the 500,000 files that couldn't be lost?

The previous system held years of operations. We built an idempotent ETL that processed the complete legacy database dump as a stream (never materializing multi-GB blob tables) and populated the new system with:

• 101,834 animals with their history and profile photo (84,160 photos)
• 81,040 guardians (the people responsible for the animals)
• 119,038 clinical records, consultations, emergencies, follow-ups, and campaign encounters
• 68,895 procedures, including 68,316 documented sterilizations
• 504,790 file attachments, clinical photos, X-rays, exam results, and signed consent forms, deduplicated by content hash

The migration taught us the project's most valuable lesson: on the first pass we worked from a partial copy of the legacy database, and three critical tables, including the historical emergencies and campaign encounters, appeared empty. Instead of assuming they were empty at the source, we reconciled the complete raw dump table by table, counting rows against the new system, and recovered all of them. That step, verifying completeness against the original source rather than an intermediate copy, is now a mandatory part of our migration playbook.

What tech stack did we use and why?

• Next.js 14 App Router + Prisma + PostgreSQL 16, the same proven pattern from our other ERPs: Server Components and Server Actions, end-to-end typing from schema to UI, and a transactional database with headroom for hundreds of thousands of records and instant search (trigram indexes for lookup by microchip, name, or guardian).
• Offline-first PWA, service worker + IndexedDB so patrols can operate with no signal: a sync queue with idempotency keys (a rescue is never duplicated even if the phone retries), on-device photo compression, and retries with backoff.
• Gotenberg (HTML→PDF) as a sidecar, the 14 official forms are rendered as HTML faithful to the contract's format and converted to PDF in a dedicated container, with digital signatures stamped via pdf-lib.
• Dual authentication, NextAuth with roles for desktop, and PIN-based sessions for the shared tablets in the clinical area, designed for the pace of a real consultation.
• Docker + Coolify on our own VPS (Hetzner), the foundation doesn't depend on a SaaS: the application, database, and PDF generator run on controlled infrastructure, with automatic deploys from GitHub.
• 3-2-1 backups with a tested restore, the database and files are backed up automatically to two different providers in different locations, and the disaster recovery procedure is documented and tested end to end, not a backup that's never been restored.

What results did we deliver?

The complete system was in production 7 weeks after kickoff (May 19, 2026), migration included. Concrete results:

• System in production and in real use by the foundation's entire team: reception, veterinarians, assistants, patrols, call center, and coordination
• Zero paper in official forms, all 14 contract documents are generated with real data and digital signatures
• All history preserved, over 100,000 animals instantly searchable with their clinical history, photos, and documents from previous years
• Field operations without connectivity, patrols register rescues with photos and GPS, and the system syncs on its own
• City government reports in minutes, what used to be a manual cross-referencing exercise now comes out of the system in one click
• Full traceability, automatic auditing of every change, in an operation funded with public resources

What did we learn?

Three lessons we now apply to every project involving legacy data or field operations:

1. You reconcile a migration against the raw source, not against a copy. A table that appears empty in an intermediate copy is not necessarily empty at the source. The only way to guarantee nothing was lost is to enumerate every table in the original dump with its real row count and explain every difference against the new system. And before any of that: ask the client to describe their old system. Three paragraphs from them expose blind spots no amount of code archaeology will reveal.

2. Offline-first is a design requirement, not a later improvement. If part of the team works where there's no signal, offline mode can't be a patch: it defines the sync architecture, the idempotency keys, and the conflict handling from day one. Adding it later means rewriting.

3. The mandatory documents define the system. Spending the first week collecting the 14 forms the foundation must deliver, before writing a single line of code, meant the data model was born correct. When the legal deliverable is a document, you design the software backwards from the document.