Source-to-target map
Trigger, inputs, transformations, state, irreversible actions, outputs, and substitutions documented before the rebuild.
ONE REPRESENTATIVE WORKFLOW · 72 HOURS · SHARED 3-SLOT CAP
When an automation tool closes or a legacy flow becomes unmaintainable, a node-for-node copy is not enough. Builderlog migrates one representative workflow into n8n with an explicit field map, five anonymous acceptance cases, evidence, and a recovery runbook.
The pilot shares the existing three-slot one-workflow inventory. No passwords, production login, or live customer records are collected.
THE MIGRATION TRAP
Trigger semantics: does the replacement start on the same event and replay boundary?
Field lineage: does each value still come from the intended source record?
Side effects: can a timeout after a committed write create a duplicate on retry?
Terminal evidence: can an empty branch silently skip the required outcome?
DELIVERABLES
Trigger, inputs, transformations, state, irreversible actions, outputs, and substitutions documented before the rebuild.
One workflow built around the confirmed outcome, using placeholders where credentials connect in your own environment.
Valid, invalid, missing, duplicate or retry, and wrong-source cases with observable expected results.
Acceptance receipt, artifact hashes, setup notes, recovery actions, and the boundary for any follow-on migration.
GOOD PILOT
Best for one workflow whose source behavior, sample input, and required outcome can be described without production access.
NOT INCLUDED
Dozens of client copies, live data migration, account administration, undocumented multi-workflow systems, and ongoing support require a separate written scope after the pilot.
3–4 WORKFLOWS × MANY CLIENTS
If one workflow is repeated across many client environments, the first deliverable should be a tenant-neutral contract—not dozens of edited copies. Separate shared workflow logic from validated client configuration, prove one synthetic tenant boundary, and deploy to one canary before any fleet rollout.
The $299 pilot covers one representative workflow. The $799 multi-client contract mode covers one process and up to three connected workflow files, a tenant-neutral configuration schema, one synthetic canary, and a rollout/rollback manifest. Neither includes bulk production deployment, live client records, client credentials, or ongoing fleet management.
EVIDENCE BEFORE PAYMENT
The public Builderlog reference packet contains three workflow JSON files, anonymous fixtures, an acceptance receipt, a recovery runbook, and a portable verifier. All three JSON files were accepted by the n8n 2.31.0 CLI importer on Node 22; the packet verifier passes 41 structural checks and 11 workflow or topology cases.
This proves importer acceptance and packet integrity only. It is Builderlog-owned reference work—not buyer-specific production execution or a customer result.
Inspect workflows, receipts, and runbook →FAQ
One existing workflow with one primary outcome and up to two external services. The source can be another automation platform, a documented manual process, or a legacy n8n workflow.
No. Builderlog works from a sanitized export, field map, and synthetic examples. Credentials and production records stay in your environment.
The handoff includes a source-to-target map, five anonymous acceptance cases, observable result evidence, artifact hashes, and a recovery runbook.
The $299 pilot covers one representative workflow. The separate $799 multi-client contract mode covers one process and up to three connected workflow files, plus a tenant-neutral configuration schema, one synthetic canary, and a rollout/rollback manifest. Neither option includes production deployment across every client account.
After the workflow boundary, sanitized source material, and expected result are complete and confirmed.
$299 CANARY · $799 MULTI-CLIENT CONTRACT