Moving Off Forth

Forth is the CRM the business grew up on. It still holds a lot of the original contact, debt, and payment data, and today Foundation reaches into it and pulls that data forward. That works — but it’s not where we’re headed. Forth is legacy, and part of doing this well is saying so plainly.

This section is deliberately different from the rest of Pitchpipe. The Glossary and Architecture describe what is. This describes what could be. It’s a living conversation, not a settled plan — and it belongs here, in the open, rather than scattered across docs and DMs.

Where things stand today

Foundation is already the system of record. New writes land in Foundation’s own models, not Forth’s.
The link to Forth is one-directional: Foundation pulls, maps legacy records into its schema, and moves on. We’re draining Forth, not building on it.
Legacy shadow models (foundation/legacy/) and the Forth API client are the seam — the clearly-marked boundary between the old world and the new one.

What “past Forth” could look like

Open questions, not decisions — this is where the sketch lives:

The data. What still lives only in Forth, and what’s the cutover plan for each slice? What’s the last thing that has to move before Forth can go read-only?
The seams. As legacy models retire, what replaces the Forth-shaped fields that leaked into the current schema (the Forth-prefixed payment records, for instance)?
The processes. Which workflows still assume Forth is in the loop, and what do they look like once it isn’t?

How to use this page

If you’re working on something that touches Forth, add what you learn here — a dependency you found, a field that turned out to be load-bearing, a slice that’s safe to cut. The goal is that when the exit plan firms up, it’s already written down, not reconstructed from memory.

Related: System Map · Integrations. Source seam: foundation/legacy/, foundation/payments/forth/.