The hard part of leaving monday.com is not the data. It's the formulas.
Exporting your boards is a solved problem. Every vendor in this category has a CSV button, and the rows come out fine.
What does not come out fine is the logic. A board that has been in use for two years has formula columns in it — status roll-ups, date arithmetic, the nested IF somebody wrote to make the RAG indicator work. Those are written in a dialect that exists inside exactly one product, and a CSV export gives you the computed value, not the expression that produced it. You get the answer and lose the question.
Why this is the step that stalls migrations
The failure is not dramatic. It looks like this: the data lands, the team starts using the new tool, and then somebody notices a column that used to update itself has been frozen since the migration. Nobody knows which columns those are, because the export did not distinguish them. So somebody opens the old system side by side and starts retyping expressions.
That work is unbounded, it is boring, and it is exactly where a migration quietly reverts.
What transpiling actually buys you
Appdor reads 7 formula dialects and compiles them to its own expression language, so the expression migrates rather than its last known output.
| What moves | Exported as CSV | Transpiled |
|---|---|---|
| Row values | yes | yes |
| Formula columns | last computed value only | the expression, still live |
| Nested conditionals | flattened to a string | recompiled |
| Cross-column references | broken | rebound to the new column |
A worked example — a status roll-up in a source dialect:
IF({Status} = "Done", 1, IF({Status} = "Blocked", -1, 0))comes across as an expression that still recalculates when Status changes, rather than as a frozen column of 1, -1 and 0.
What it does not buy you
Transpilation is not a promise that every expression survives. Dialects differ in ways that are not always expressible:
- A function with no counterpart has to be rewritten, not translated. The compiler tells you which ones; it does not invent semantics.
- Formulas that depend on vendor-specific board structure — a column type that has no equivalent — need a modelling decision from a person.
- Timezone and week-numbering behaviour differs between dialects, and a date formula that was subtly wrong before will be subtly wrong differently.
Saying so is not hedging. A migration tool that claims a 100% rate is a migration tool you will stop trusting on the first expression it silently got wrong, and then you will re-check all of them by hand — which is the cost you were trying to avoid.
The order that works
- Export the rows. This part is genuinely easy; do it first so you have a fallback.
- Inventory the formula columns before you migrate. You want the list while you still have the old system to read.
- Transpile, and read the compiler's refusals. That list is your real migration backlog, and it is usually much shorter than the inventory.
- Rebuild the refusals by hand, then diff a sample of computed values against the old system before you switch anybody over.
Step 4 is the one people skip, and it is the only step that proves the migration worked.