Migrate a service portfolio from ServiceNow or Jira

This guide is the customer’s view of a migration. The platform side is described in Record sessions and Plans and governance.

Goal

Move one service portfolio into FlowLakes: a named set of your services, with their records, approvals, service commitments and integrations. You run three stages in order, and at the end FlowLakes is where that portfolio’s daily work happens.

One portfolio at a time. A second portfolio starts again at stage one.

Prerequisites

An administrator with platform.tables.write for the portfolio’s tables and platform.external.config.write for its connections.
A person who can read the export, which needs platform.data.export.
A named accountable owner for every service in the portfolio.
Your existing tool still running. Nothing in stage one asks you to stop using it.

What you provide

Four things, and the migration cannot start without the first two.

The dependency inventory. A list of everything you actually use in your current tool for this portfolio: intake channels, record types, calendars and SLA rules, approvals, integrations, reports, retention obligations. Your FlowLakes contact brings a template with one table per area. What matters is that it is your real usage rather than a feature list. A dependency nobody writes down is the one that stops a cutover on the day.
The field map. For every record type, which field in your tool becomes which field in FlowLakes, which states map to which states, and which fields are deliberately left behind. Agree this with the service owner before anything is imported.
Your thresholds. Before the pilot starts, you say what good looks like: how much of the incoming work the platform must handle, how much of that must close with the outcome verified, how long an approval may wait, how many SLA breaches are acceptable, what a recovery must cost in time. If the thresholds are blank, nobody can say afterwards whether the migration worked.
Your retention rules. What has to be kept, for how long, and where. Some records are migrated, some stay in a readable archive of the old tool, and the two lists are yours to decide.

Stage 1: shadow

FlowLakes holds a copy of your portfolio’s records and watches. Your current tool stays the authority, and your people keep working there.

Your records are imported with their original timestamps and their identifiers from the old tool, each one marked as owned by that tool.
Every connection stays at the observe posture. Nothing FlowLakes proposes reaches an outside system.
Sessions do not start on their own. A record landing in FlowLakes during shadow mode wakes nothing, and automated rules do not write to a record the old tool owns.
Each week you read the service operations health page together with your FlowLakes contact and write the numbers into the measurement sheet. These weekly readings are the baseline your cutover is judged against.
You compare what the platform suggested against what your people actually did. The disagreements are the most useful output of this stage. Each one is logged.

What you see. Your records in FlowLakes, with the platform’s suggestions beside them. Your work continues where it is. Nobody is asked to work in two places.

You leave shadow when every blocking item in the inventory has become either replaced, archived, or an accepted gap with your name against it.

Stage 2: cutover

FlowLakes becomes the authority for the portfolio. This is a scheduled event, table by table.

The checklist is signed first. Mapped dataset, reconciliation results, named operating owners, your thresholds, the rollback triggers, the recovery procedure, and the one-authority rule below. All seven.
Work is frozen in the old tool for the table being flipped, for an announced window.
The delta is imported: everything that changed in the old tool since the last shadow import.
Reconciliation runs on the delta: counts per state, timestamps, relationships, attachments, audit history, ownership. Anything that does not match is resolved before the flip, or accepted in writing by the service owner.
Authority flips to FlowLakes for the table. The ownership readout then shows no records still owned by the old tool.
Sessions are switched on if you want a new record to start a run by itself. This is a separate decision and it can wait a week.
Connections move from observe to assist. The platform proposes freely and executes only after a person approves. Nothing moves to the trusted posture at cutover.
Work resumes, in FlowLakes.

The one-authority rule. From the flip, exactly one system owns each record, and it is FlowLakes. The old tool is read only for that table. If somebody has to open the old tool for a migrated record, that is a fault in the migration and it gets recorded as one. Approvals that were made in the old tool travel with the record as history; they never authorize a fresh change.

Stage 3: observation, then retirement

Agree the period before the flip, with a start date. A sensible floor is one full business cycle: the period that contains your month end, your change window and your slowest SLA.
Read the measurement sheet weekly against the thresholds you set. Two numbers matter most: how much of the incoming work the platform supports at all, and how much of that closes with the outcome verified. Rising unsupported work means the inventory missed something.
Walk the inventory once more at the end of the period. Confirm each archived dependency is still readable by the person who will need it, and confirm each accepted gap is still accepted, with a date.
Run the exit test. Export the portfolio and read it yourself: fields, relationships, the activity timeline, the attachment list, the audit history. This proves you can leave, which is a different question from whether you want to.
Retire the old tool’s connections for this portfolio by name: inbound feeds, outbound calls, reporting consumers, scheduled jobs.
Withdraw access to the old tool last. Removing access before step 3 turns a readable archive into a lost one.

What stays yours

The point of the migration is that authority moves to you, not away from you. After cutover, without opening the retired tool:

Approvals are yours. Every change outside FlowLakes is a plan a person approves, and who may approve it is decided by your approval ladder before the work runs. A step that matches no rule is refused rather than quietly executed. Nobody approves their own request.
Takeover is yours. Any record’s session can be taken over from its audit account, behind the rail’s Audit link. The session stops at its next turn, keeps everything it recorded, and starts nothing until you hand the record back.
Revoking delegation is yours. Standing authorization for a connection is earned from verified outcomes, and you withdraw it at any time by moving the connection’s posture back or removing the operation. The next run stops.
Your configuration survives an upgrade. Connection postures, house rules, routing and approval policies you set are preserved through installs and module updates.

What FlowLakes does not yet replace

Read this list against your inventory before you agree a cutover date. If your portfolio depends on one of these, the date moves.

Email and chat intake. A record cannot be raised by sending an email or a chat message. The portal, a form and the API are the intake channels.
Inbound webhooks. FlowLakes can call other systems and sign the call. It cannot yet receive an event from one, so a monitoring tool cannot open an incident by itself.
On-call rotations. There is no rotation or paging. Out of hours escalation reaches a fixed list of recipients.
Knowledge articles for people. The platform keeps its own operational memory of past cases. There is no authoring, review and publication lifecycle for articles your staff read.
Governance exports. Audit history travels inside the record export. There is no separate audit export, no export of who holds which role, and no periodic separation of duties report. Your auditor may need one of these.
CSV. The export is JSON Lines, one record per line. A reporting tool that requires CSV converts it on your side.
Attachment backup. The nightly database backup does not include the attachment files themselves. A restore returns the record and its list of attachments. The files themselves have to be copied separately.
A timed recovery drill. Restores are exercised weekly against a copy of production, which shows that a restore works. Nothing yet measures the recovery against a contractual recovery time.
A named model outage mode. If the model provider is unavailable, intake, the record lifecycle and your SLA clocks carry on. Sessions fail, and they fail one by one as ordinary errors rather than as a single visible outage.
Problem management on the current spine. Problem records exist in the older blueprint only. Decide with your FlowLakes contact whether that is enough for this portfolio.

Verification

You know the migration worked when all of these are true:

The ownership readout for every table in the portfolio shows FlowLakes and no remaining records owned by the old tool.
Your reconciliation has no open discrepancies in counts, timestamps or ownership.
The weekly measurement readings sit at or above the thresholds you set before the pilot, for the whole observation period.
One of your own people picks an executed change at random and can answer, from FlowLakes alone: what was asked, what was read, what was proposed, who approved it, what happened, and what changed outside.
You run the exit test and read the export yourself.
Every remaining dependency on the old tool has a written disposition, and a name against it.

A single demonstration, however convincing, does not meet this bar. Daily operations for the whole portfolio do.

Troubleshooting

Symptom	Cause	Fix
An imported record shows the wrong dates, or its SLA is already breached on arrival	The extract or the field map moved the timestamps. The import keeps whatever the source sends	Correct the extract, re-import the affected records (the import is idempotent on the old tool’s identifier), and rerun the timestamp comparison before flipping
The platform proposed nothing on records it should have worked	Sessions are not switched on for the table, or the record is still owned by the old tool	Check the table’s session setting and the ownership readout. During shadow mode both are intended
A change was approved but nothing happened outside FlowLakes	The connection is still at the observe posture, or the plan matched no approval rule and was refused at creation	Check the connection’s posture on its page and the approval ladder’s readout for that connection
People are still opening the old tool for migrated records	A dependency the inventory missed, most often an intake channel or a report	Log it as a migration fault, add the row to the inventory with a disposition, and decide whether it is a rollback trigger

Related: Record sessions explains what the platform does with a record once it owns it, and Plans and governance explains who approves what it proposes.