Migrating Prompt Templates Out of a No-Code Platform

The prompt you can see in the editor is a fraction of what actually gets sent. Copying the text out and pasting it into a file produces something that looks right and behaves differently, and the difference is always in the parts the interface renders as controls rather than as text.

Decide the target format first

Extraction without a target schema produces a folder of text files and a second migration later. Define the destination before you open the first prompt, because the schema is what tells you which fields you are still missing.

A prompt is not a string. It is a string plus the model configuration that makes the string behave, plus the variables it expects, plus the output contract it promises. All four belong in one versioned record:

# prompts/support-triage.v3.yaml
id: support-triage
version: 3
messages:
  - role: system
    content: |
      You classify inbound support messages.
      Reply with JSON only.
  - role: user
    content: |
      Ticket: {{ticket_body}}
      Customer tier: {{tier}}
model:
  primary: <provider>/<model-string>
  temperature: 0
  max_tokens: 512
  stop: ["\n\n---"]
variables:
  ticket_body: {required: true}
  tier:        {required: false, default: "standard"}
output:
  format: json_schema
  schema_ref: ./schemas/triage.json

Everything below is an argument about how to fill in each of those blocks from a UI that was not designed to give them to you. Keep the records in the repository next to the code that calls them — the point of leaving the platform is that the prompt becomes a reviewable artefact, which means it goes through the same pull request as the code path that sends it. A prompt registry is the shape this grows into once there are more than a handful.

Inventory before you extract

Do the accounting pass first, in one sitting, because the count changes the plan. Walk every workspace, project and folder and record the prompt name, where it is invoked from, whether it is live, and when it was last edited. Two things fall out of this that are worth more than the extraction itself.

The first is dead weight. Builder platforms accumulate drafts, and a typical workspace has a large fraction of prompts that nothing calls. Migrating them costs the same as migrating the live ones and produces maintenance forever. If a prompt has no invocation path and no edit in months, it is a candidate to leave behind — record it in the inventory as skipped rather than deleting it, so the decision is auditable.

The second is duplication. Builder UIs make copying a prompt a single click and make parameterising one hard, so the same instruction tends to exist in five near-identical variants that differ by a sentence. In code those collapse into one template with a variable. Spot them at inventory time, because collapsing five records into one is a design decision and doing it accidentally during extraction is how a behavioural change gets shipped as a refactor.

The fields the UI does not show you

This is where a naive copy loses fidelity. Each of these is set somewhere in the interface but does not appear in the prompt body, so it is absent from anything you copy out of the editing pane.

• The system message. Often a separate collapsed panel labelled “instructions”, “persona” or “role”. Sometimes there is a platform-level system message applied to every prompt in the workspace, set once in settings and never seen again. Look for it explicitly; a prompt that worked and then stopped working after migration is very often a missing workspace-level preamble.
• Sampling parameters left at their defaults. A slider you never touched still has a value, and it is not necessarily the value your new SDK defaults to. Record temperature, top-p, penalties and the stop sequences as explicit numbers even where the UI shows them greyed out. This is the single most common source of “the same prompt behaves differently now”.
• Max output tokens. Platform defaults are frequently small. Migrating without it and getting truncated output looks like a model regression and is a configuration loss — the two limits it sits between are worth being precise about before you pick a number.
• Variable syntax and defaults. The delimiters differ per platform, and so does the behaviour on a missing variable: some substitute empty, some leave the placeholder literal in the prompt, some refuse to run. Whatever your new templating layer does, it must do the same thing or you inherit a class of bug that only fires on the input that omits the field.
• The output contract. A toggle called “JSON mode” and a schema pasted into a panel are two very different things, and they map onto different request fields. Record which one was on, and the schema text verbatim.
• Retry and fallback behaviour. Configured per prompt on some platforms. It is not part of the prompt, but it is part of what the prompt’s observed success rate depended on, so it goes in the inventory as a note against the record.

The extraction procedure

1. Take the platform’s own export first, whatever it gives you. Even a partial JSON dump is a better starting point than the screen, because it names the internal field keys. Check the account settings and the API section as well as the per-prompt menu; the export is often a separate feature from the download button on the editor.
2. Capture the raw request if the platform will show it. A request log, a debug pane or a trace view that shows the exact payload sent upstream is the highest-fidelity source available, because it contains the assembled result of every hidden default. One captured payload per prompt settles the parameter questions above without guessing.
3. Copy the prompt body from a plain-text view, not the rich editor. Rich editors substitute typographic quotes and en-dashes. In a prompt that instructs a model to emit JSON, a curly quote inside an example is a real defect. Diff the copied text against the original for non-ASCII characters before you accept it.
4. Write the record in your target schema, filling every field explicitly. No inherited defaults. If you do not know what the platform used for top-p, that is an open question in the inventory, not a blank in the file.
5. Freeze a fixture set per prompt. Ten to thirty real inputs with the outputs the platform produced for them, captured before you switch anything off. This is the only artefact that lets you tell a faithful migration from a plausible one, and it cannot be reconstructed after the account is closed.

Proving the extraction is faithful

Run the extracted record against the same provider and model the platform used, with the fixtures from step five, before you change anything else. This is the whole reason to do the migration in two moves rather than one: if you change the harness and the provider together and the output shifts, you have no way to attribute the shift.

Compare at the level the application cares about. For a classifier that is exact label match; for extraction it is field-by-field equality on the parsed object; for free text it is whatever check your existing golden dataset already applies. Byte equality is the wrong bar unless temperature is zero, and even then zero temperature is not a determinism guarantee.

Expect a small number of prompts to disagree, and treat each disagreement as a missing field rather than as an acceptable variance until proven otherwise. In practice the residue after one pass is almost always a stop sequence, a workspace preamble, or a max-token cap. Only once the extracted prompts reproduce the old behaviour should you start changing model, provider or structure — and at that point the fixtures you froze become the regression suite for that change too. The components that will not come out at all are a separate problem, covered in what a no-code platform does not let you export.