How it works

Six stages from source to loaded record

Every migration follows the same disciplined pipeline — with comparison and preview checkpoints built in so surprises surface early, not after the load.

Connect → Extract → Compare → Compile → Transform → Load

01

Connect

Register QAD/Progress source systems and manage extract profiles, including client overlays — Jinja2-templated Progress scripts such as a QAD EB2 item master extract.

02

Extract

Pull data from source systems over SSH, normalize it, and stage it for mapping. Scheduled runs and watch-folder drops feed this stage automatically.

03

Compare

Diff datasets before committing: file vs. extraction and extraction-to-extraction comparisons surface unexpected changes early.

04

Compile

Turn Excel mapping workbooks into executable load maps: formula evaluation, cross-references, and starter-map generators for REST and Qxtend targets.

05

Transform

Apply the rules engine and mapping transforms, then dry-run preview the result before any data touches the target.

06

Load

Execute runs through the job queue and push records into QAD via REST, Qxtend, or QDoc adapters; webhook notifications report outcomes.

Supporting services run alongside the pipeline: the scheduler triggers extraction runs on a cadence, the watch folder auto-ingests dropped files, and webhook notifications report run outcomes.

Under the hood

Server-rendered and self-contained

A FastAPI service with server-rendered pages and light JavaScript — no heavy frontend build. SQLite storage with inline migrations; artifacts live on the filesystem where you can inspect them.

Deploys anywhere Python runs

A single service behind your reverse proxy, reaching QAD sources over SSH — even legacy hosts. Role-based access, bcrypt credentials, login lockout, and a health endpoint for monitoring.

See it against your data

Bring a mapping workbook and a source system — Andy handles the rest.

Get in touch