> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ouraicalling.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate from Famulor 1.0

> Preview and safely import assistants, tools, knowledge-base shells, campaigns, and automations

Open **Settings → Workspace → Data migration** to connect a Famulor 1.0
account with its API key. The key is used only while the preview or import
request is running. It is never stored, logged, cached, or returned.

Alternatively, ask **Milian** to “move my assistants from Famulor 1.0”.
Milian shows a secure authorization card. After you click **Authorize
Famulor 1.0**, the Famulor 1.0 OAuth page opens and returns to the same Milian
conversation. Milian then:

1. reads the available migration tools through the Famulor 1.0 MCP endpoint,
2. previews assistants, automations, campaigns, tools, and knowledge bases,
3. asks whether to migrate everything or selected source IDs/names and whether
   to include all related tools and knowledge bases, and
4. imports only the confirmed selection.

The OAuth access and refresh tokens are encrypted, workspace-scoped, and
renewed server-side. They are never included in the Milian conversation.

## Log in with your Famulor 1.0 account

If you already have a Famulor 1.0 account, you can log in directly on this
platform's main domain using your old email and password — no separate
sign-up needed. On first login, a matching account is created here
automatically (a platform-root workspace).

After that, one-click migration no longer requires pasting an API key: open
**Settings → Workspace → Data migration** and click **Connect with my Famulor
1.0 account** on the Connect step. It runs the same preview and import as the
API-key flow, just authenticated through your login instead of a pasted key.

<Note>
  Platform admins enable this login bridge by setting the
  `FAMULOR_V1_WHITELABEL_ADMIN_KEY` environment variable to the white-label
  admin API key of `app.famulor.de`. This key stays server-side and is never
  exposed to the client. Without it, the bridge is disabled and the Connect
  step falls back to the API-key flow only. The bridge only works on the
  platform's main domain — never on white-label reseller domains — answers
  neutrally on any failure (it never reveals whether an account exists on
  either platform), and is rate-limited.
</Note>

## Resource links and tool migration

* Famulor 1.0 built-in tools are read from each assistant, created as separate
  entries in the central **Tools** library, and assigned only to that source
  assistant. This includes end call, cold/warm transfer, DTMF/keypad collection,
  and assistant transfer. Assistant-transfer targets are resolved after all
  selected assistants have been created, so forward references are preserved.
  DTMF and keypad collection are flow-only on the new platform: the migration
  creates and assigns them, but you must place the matching DTMF or Collect
  node in Flow Builder before they execute.
* Selected custom HTTP mid-call tools are also created in the central Tools
  library. The Famulor 1.0 read API returns these tools account-wide without
  their `tool_ids` assistant links, so every selected custom tool is assigned
  to every assistant imported in the same run.
* A `calendar_integration` with usable Cal.com credentials (an API key and an
  event type ID) becomes a native calendar integration and is assigned to its
  source assistant instead of being duplicated as a built-in tool. Calendar
  entries for other providers (for example Calendly) or Cal.com entries
  missing usable credentials are **not** imported — reconnect that calendar
  manually under **Integrations** after import. Calendly itself is natively
  supported on the new platform via its own OAuth connection, so reconnecting
  it does not require an API key.
* Selected knowledge-base shells are created before assistants. If an assistant
  references one of those selected knowledge bases, the new knowledge-base ID
  is written to that assistant automatically. Famulor 1.0 does not expose the
  document bodies, so documents still need to be added again.
* Famulor 1.0 `dualplex` assistants are imported in **Half-cascade** mode.
* The preview lists each assistant's individual built-in tool configurations
  (call transfer, DTMF, end call, and so on) in its details, so you can review
  exactly what will be created before importing.

If the source account's plan does not include automations, the source API may
return HTTP 403 for only that resource family. Preview and import skip
automations in that case and continue with all other selected resources.

<Note>
  The canonical callback uses `NEXT_PUBLIC_APP_DOMAIN` (for example
  `app.famulor.io`). You can override it with
  `FAMULOR_V1_OAUTH_REDIRECT_BASE_URL=https://app.famulor.io`. Allowlist that
  origin in the Famulor 1.0 OAuth server. The callback returns to the original
  whitelabel conversation after the canonical exchange.
</Note>

## Recommended workflow

1. Generate the preview and review every warning.
2. Import assistants before campaigns and automations so their bindings can be
   restored in the same run.
3. Reconnect phone numbers, messaging senders, approved WhatsApp templates,
   calendars (any provider other than Cal.com, and Cal.com entries that had
   no usable credentials), and knowledge-base documents on the new platform.
4. Open every imported campaign and automation, repair review items, test it,
   and activate it manually.

Voice campaigns keep their assistant, timezone, daily/overnight windows,
concurrency, retry policy, and goal settings when those resources can be
resolved. Scheduled or running source campaigns are always reset to drafts.
WhatsApp and SMS campaigns remain unimportable until their target sender,
template, or sending number has been connected because Famulor 1.0 resource
IDs are not portable. The source campaign endpoint does not expose its
audience, so leads must be imported or assigned separately.

Automations are always created as disabled drafts. Native mappings cover
assistant-event, webhook, schedule and manual triggers plus HTTP, webhook
response, delay, SMS, outbound-call, contact-upsert, and workspace-email
steps. Unsupported integrations and legacy code are preserved as visible
review nodes instead of being silently dropped or executed.

## REST API and MCP

Use `POST /api/v1/migrations/famulor` with `action: "preview"` first, then send
`action: "import"` with the exact selected source IDs. The target API key needs
read permission for preview and the matching write scope for every selected
resource family.

The API-key flow is available as the MCP tools
`preview_famulor_1_migration` and `import_famulor_1_data`. REST is recommended
for unattended bulk migration. Milian uses the source MCP OAuth connection
instead of asking for a source credential, while still running the same
deterministic mapping and draft-safety rules.

<Warning>
  The Famulor 1.0 MCP endpoint uses its own OAuth flow. A Famulor 1.0 REST API
  key does not authenticate that MCP endpoint. Never paste an API key into a
  Milian conversation; use the authorization card.
</Warning>