Skip to content

Case study · Qualis

Modernizing a manufacturer's quality system without stopping production.

A step-by-step replacement of an aging desktop quality management system with a modern web platform, migrated module by module while the factory keeps running.

Discuss a similar projectSee the architecture
Sector
Industrial manufacturing
Services
Scope
Assessment to full migration
Core stack
TypeScript, React, Node.js, PostgreSQL, REST APIs
Illustrative case study

This case study shows how we would approach a representative project of this kind. It is not a record of a specific client engagement: names, interfaces, and plans are examples, and outcomes are described as what would be measured rather than as results.

USERSShop-floor tabletsQuality officeAuditors · read-onlySingle sign-onINDIVIDUAL ACCOUNTS · ROLES · AUDIT TRAILModule routerSends each module to the legacy system or the new platform. Switchable per module.LEGACY DESKTOP SYSTEM · SHRINKINGInspectionsMOVEDNon-conformancesMOVEDCorrective actionsIN USESupplier qualityIN USENEW QUALITY PLATFORM · GROWINGInspectionsLIVENon-conformancesLIVECorrective actionsMIGRATINGNEXT: SUPPLIER QUALITYLegacy databasePostgreSQLDATA BRIDGEERPORDERS · BATCHESSUPPLIERSQualis · migration architectureSTAGE 3 OF 5 · CORRECTIVE ACTIONSSHEET 02ILLUSTRATIVELEGACYIN MIGRATION

Scroll sideways to see the full screen

Interface conceptMigration architecture: a routing layer moves modules from the legacy system to the new platform one at a time.

§ 01The situation

Where things stand.

A manufacturer runs its quality processes (inspections, non-conformances, corrective actions, and supplier quality) on a desktop application built two decades ago, on a database that only a few long-serving employees fully understand.

The system works, but it cannot be used on the shop floor, does not connect to the ERP, and no longer meets the company's security requirements. Replacing it in one step is too risky: quality records are needed on every shift, and audits depend on their history.

What makes it hard

  • Undocumented logic

    Business rules live in stored procedures and in the memory of a few people.

  • No room for downtime

    Production cannot pause for a cut-over weekend that might overrun.

  • Audit history

    Years of records must remain complete, traceable, and available to auditors throughout.

  • Security gaps

    The legacy system uses shared database credentials and has no individual user accounts.

§ 02The solution

What we would build.

Each part answers one of the problems above, and each can be delivered and tested on its own.

System assessment
Legacy screens, data, and stored procedures cataloged, and business rules documented with the people who rely on them.
Incremental replacement
A routing layer sends each module to either the legacy system or the new platform, so modules move one at a time and can be switched back if needed.
New web platform
A shop-floor-friendly web application with individual accounts, role-based access, and a full change history.
Two-way data bridge
During the transition, records stay synchronized between the old and new databases, so both systems show the same truth.
ERP integration
Non-conformances linked to ERP production orders, batches, and suppliers instead of being typed in twice.
Verified migration
Historical records migrated with automated checks that compare counts, totals, and samples against the source.

§ 03Architecture

How the pieces fit.

A layered view of the proposed system. The highlighted component carries the logic the rest of the system depends on, so it is designed and tested first.

  1. 01 Users

    • Shop-floor tablets
    • Quality office
    • Auditors (read-only)

  2. 02 Routing

    • Single sign-on
    • Module router

  3. 03 Applications

    • Legacy desktop system (shrinking)
    • New quality platform (growing)

  4. 04 Data

    • Legacy database
    • Two-way data bridge
    • PostgreSQL
    • ERP API
Architecture overviewQualis, by layer. Core technologies: TypeScript, React, Node.js, PostgreSQL, REST APIs, Docker, AWS.

§ 04Delivery plan

Delivered in stages you can review.

Each stage ends with something working that you can evaluate before committing to the next.

  1. Stage 01

    4 weeks

    Assessment

    Catalogue the legacy system, document its rules, and define the migration order and acceptance checks.

  2. Stage 02

    6 weeks

    Foundation

    Identity, routing layer, data bridge, and the core of the new platform.

  3. Stage 03

    4–6 weeks each

    Module migration

    Inspections first, then non-conformances, corrective actions, and supplier quality, each verified before switching.

  4. Stage 04

    4 weeks

    Decommission

    Final data migration, an archive of the legacy system, and retirement of the old database.

§ 05Outcomes

What you receive, and how success is measured.

Targets for each measure are agreed during discovery, using your current figures as the baseline, and reported on throughout delivery.

Deliverables

  • Documented business rules and data model
  • New quality management web platform
  • Routing layer and data bridge for the transition
  • Verified migration of historical records
  • ERP integration and a decommissioning plan

Measured by

  • Modules migrated without unplanned downtime
  • Records entered twice across quality and ERP
  • Time to retrieve records for an audit
  • Users with individual, role-based accounts

§ 06Start a project

Planning something similar?

Describe where things stand today and what needs to change. We will reply with questions and an initial view of scope and approach.

Discuss Your Project[email protected]
  1. 01

    Share the context

    A short description of the project, your goals, and any constraints you already know about.

  2. 02

    We review it

    We read it carefully and reply with questions or an initial perspective on the problem.

  3. 03

    A first conversation

    A call to explore scope, approach, and whether we are the right fit for the work.