Source: https://guthlabs.ai/docs/project-templates/operations-migration/forms/

project template / candidate

# Operations migration — forms

The distinct forms record for Operations migration. This page is proposal-only.

Status: **proposed**Lifecycle: **candidate**

## Record status

**Record ID**: project:operations-migration

**Parent lifecycle**: candidate

**Page lane**: forms

**Lane lifecycle**: proposed

**Owner**: Not separately recorded

**Owner role**: Not separately recorded

**Owner status**: Not separately recorded

**Qualification result**: NOT RUN · held for evidence and human review

**Working browser surface:** [Project templates & workflows — overview](<https://guthlabs.ai/labs.html#templates-workflows>) — Create a local project from this template and validate its forms. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held.

## Proposed form sections

Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth.

### Intake

Define why the migration is proposed, who owns it, and what decision is being requested.

- project title

- requester

- project owner

- operations owner

- source system description

- destination system description

- operational capability being moved

- reason for migration

- desired outcome

- requested start date

- target completion date

- business or operational constraints

- known affected teams

- initial success measures

- visibility and access classification

- source references

### Scope

Set explicit boundaries and prevent unapproved expansion.

- in-scope processes

- in-scope records or data classes

- in-scope users or teams

- in-scope time period

- out-of-scope processes

- out-of-scope records or data classes

- out-of-scope users or teams

- migration method proposal

- cutover boundary

- data retention requirement

- reconciliation requirement

- rollback requirement

- assumptions

- open scope questions

- scope approval status

### Milestones

Break the work into ordered, reviewable outcomes.

- milestone ID

- milestone name

- milestone purpose

- deliverable

- milestone owner

- planned start

- planned finish

- acceptance condition

- predecessor milestones

- status

- evidence required

- reviewer

- approval required

- completion notes

### Deadlines and Workback

Create source-bound deadlines and calculate the workback from the target completion date.

- target completion date

- cutover date

- rollback decision deadline

- reconciliation deadline

- approval deadline

- evidence submission deadline

- communications deadline

- training or handoff deadline

- milestone duration

- workback offset

- due date

- priority

- recurrence candidate

- completion state

- deadline rationale

- date owner

- date change reason

- revision note

### Dependencies

Identify prerequisites, external decisions, sequencing constraints, and blocking states.

- dependency ID

- dependency description

- dependency type

- blocking milestone

- dependency owner

- required-by date

- status

- source or destination affected

- evidence of satisfaction

- fallback if unavailable

- escalation owner

- escalation deadline

- dependency risk

### Owners and Responsibilities

Assign accountable people to each decision, action, review, and receipt.

- role

- named owner

- backup owner

- responsibility statement

- assigned records

- decision authority

- review authority

- communication responsibility

- availability window

- handoff condition

- assignment status

### Tools and Guides

Declare which observed local surfaces and source-backed guides may support the work without implying external execution.

- tool or surface name

- tool kind

- intended use

- canonical record owner

- required access

- operator

- guide reference

- usage boundary

- execution status

- held external effect note

### Evidence

Capture reproducible receipts for preparation, migration, reconciliation, rollback testing, and review.

- evidence ID

- evidence type

- claim supported

- record or milestone linked

- source locator

- source SHA-256 if available

- captured by

- captured at

- input conditions

- expected result

- observed result

- reconciliation method

- attachment or local file reference

- provenance note

- review status

- reviewer comments

### Approvals

Make consequential decisions explicit and preserve the local review receipt.

- approval ID

- decision requested

- decision owner

- reviewers

- decision options

- recommendation

- required evidence

- decision deadline

- status: Needs review, Approved, or Held

- decision rationale

- conditions

- receipt reference

- revision

- reconsideration trigger

### Risks and Failure States

Plan for data loss, mismatch, timing failure, access failure, unsafe cutover, and rollback conditions.

- risk ID

- risk statement

- category

- likelihood

- impact

- risk owner

- early warning signal

- mitigation

- contingency

- trigger threshold

- affected milestone

- due date

- current status

- residual risk

- escalation path

- failure-state notes

### Closure

Confirm the migration outcome, unresolved work, evidence completeness, and rollback disposition.

- closure owner

- completion date

- capability status

- scope delivered

- scope deferred

- reconciliation result

- unresolved discrepancies

- rollback readiness result

- rollback window end

- handoff recipient

- operating guide reference

- final evidence set

- outstanding risks

- follow-up deadlines

- final approval

- closure decision

- closure notes

### Accessible state contract

- Every field requires a visible and programmatic label.

- Required and optional fields must be stated in text.

- Invalid entries require an actionable message linked to the field.

- Blocked and Held states remain visible without relying on color alone.

## Supporting documentation fields

These fields come from the app_features lane and remain separate from the primary operating form.

### Migration identity

Define the capability move and its record ownership.

- project title

- capability name

- migration owner

- source system label

- target system label

- scope statement

- success criteria

- project tags

### Source and target baseline

Capture comparable, source-labelled facts without implying connected systems.

- source record references

- target record references

- source locator

- target locator

- source snapshot date

- target snapshot date

- source evidence file references

- target evidence file references

- known gaps

- assumptions

### Deadlines and workback

Set the migration deadline and derive reviewable preparation steps.

- migration deadline

- freeze deadline

- reconciliation deadline

- rollback decision deadline

- workback tasks

- task owners

- task due dates

- task priority

- dependency links

- recurrence candidate

- completion state

### Reconciliation and rollback

Make differences, acceptance conditions, and reversal evidence explicit.

- comparison dimensions

- expected count or value

- observed count or value

- difference classification

- unresolved discrepancy

- rollback trigger

- rollback steps

- rollback evidence reference

- rollback owner

### Approval and projection

Stage human review and summarize current project risk in PointGuard.

- review status

- reviewer

- approval note

- held decision reason

- current phase

- risk level

- blocking items

- next action

- PointGuard projection label

## Required or proposed record references

No record existence is asserted by this documentation page.

- project record

- scope record

- milestone records

- deadline and workback to-dos

- dependency records

- owner assignments

- tool and guide links

- evidence records

- approval records

- risk records

- closure record

- project record with canonical ID, lifecycle, provenance, revision, tags, links, and attachments

- source-system capability record

- target-system capability record

- migration workback todo records

- reconciliation result record

- rollback plan record

- approval record

- file reference records for evidence

- PointGuard context projection record

## Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

- `source_record:project:operations-migration`

- `NotebookCollectionKind.project`

- `NotebookTodoPayload.dueAt`

- `Notebook Agenda deadlines/workbacks`

- `Observed native contract: project_and_field_guide_collections`

- `Observed native contract: deadlines`

- `Observed native contract: records`

- `Observed native contract: pointguard`

- `Observed native contract: web_boundary`

- `App route: /app/notebook/projects/`

- `App route: /app/notebook/to-dos/`

- `App route: /app/notebook/agenda/`

- `App route: /app/notebook/approvals/`

- `App route: /app/notebook/files/`

- `App route: /app/notebook/notes/`

- `App route: /app/notebook/field-guides/`

- `App route: /app/notebook/agent-logs/`

- `App route: /app/pointguard/`

- `Notebook records canonical IDs, provenance, revisions, links, and attachments`

- `PointGuard persistent cross-app context surface`

- `APP_ROUTES /app/notebook/projects/`

- `APP_ROUTES /app/notebook/agenda/`

- `APP_ROUTES /app/notebook/to-dos/`

- `APP_ROUTES /app/notebook/approvals/`

- `APP_ROUTES /app/notebook/files/`

- `APP_ROUTES /app/notebook/agent-logs/`

- `APP_ROUTES /app/pointguard/`
