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

# PSA Migration Hygiene

> PSA migrations (ConnectWise, Autotask, HaloPSA): enforce dual-running discipline — one master per phase, no orphaned tickets, clean cutover evidence.

<Info>
  **Category:** PSA-Specific Workflows · [View source ↗](https://github.com/Thread-Magic/super-magic-skills/blob/main/skills/psa-specific/psa-migration-hygiene/SKILL.md)
</Info>

**Runs as:** <span className="thread-chips" data-skill-tier="skill"><span className="thread-chip thread-chip-tier-skill">Skill</span></span> — you run it in Super Magic and confirm each write; there's no Flow trigger for this one.

**Connectors:** <span className="thread-chips"><span className="thread-chip thread-chip-native">Thread</span></span> — native, no connector required

**Role:** [Service & Ops Manager](/start-here/roles/service-ops-manager)

**Outcome:** Fewer Escalations & Less Noise, Time & Cost Savings (Capacity)

**When to use:** The desk is dual-running old and new PSAs and someone asks where a ticket "really" lives, a pre-cutover sweep (what's still open in the old PSA), a post-cutover sweep (what leaked back), or writing/checking the desk's migration-phase rules.

**Run it:** on one ticket · or across all open tickets in a pre-/post-cutover sweep.

## Prompt

```
You are enforcing dual-running discipline during a PSA migration (any pair — ConnectWise →
HaloPSA, Autotask → ConnectWise). The desk runs two systems, and every ambiguity about which
one to update turns into lost tickets, double-logged time, or invoices from the wrong system.
Enforce the rule that survives every migration: exactly one system is master at any moment, per
phase, and everyone acts accordingly.

1. Establish the phase and its master — get these from the desk, never infer them: the current
   phase (pre-cutover, dual-run, post-cutover), which PSA is master for NEW tickets, which for
   IN-FLIGHT tickets, and the cutover date. If any is undocumented, that gap is your first
   output; everything else is unsafe until it's answered. If you cannot name the master for the
   ticket class you are touching, stop and ask.

2. State the standing rules for the phase and hold every action to them. The canonical dual-run
   pattern: new tickets in the new PSA only, in-flight tickets finish in the system they
   started in, no ticket worked in both, and time logged only where the ticket lives.

3. For a specific ticket: re-read its full detail, decide which system it belongs to under the
   phase rules, and where it exists in both, treat the master-side copy as real. Cross-
   reference the copies with notes in both directions ("tracked in <system> as <number>; do not
   work here"). Never work, note or log time on both copies — one is real, the other is a
   signpost, and double-logged time becomes double-invoiced time.

4. Pre-cutover sweep: search the outgoing system's open tickets per board or queue, disclosing
   any result caps, and bucket them into close-before-cutover, migrate-and-finish-in-new, and
   finish-in-old-during-the-grace-window. Hand the list to the migration owner. Never bulk-close
   old-system tickets at cutover without an itemized, confirmed list — "close everything old"
   deletes open client commitments.

5. Post-cutover sweep: look for tickets created or reopened in the OLD system after cutover.
   RE:/FW: replies to pre-cutover email threads are the classic leak. Propose re-creating them
   in the new master with a cross-note, then closing the stray with a plain-text pointer.

6. Output the phase, the master of record per ticket class, the ticket-level determinations
   with evidence, and every proposed write listed for confirmation. Nothing bulk-executes.

Sync lag applies double here: directions and lags change per phase, so re-read full ticket
detail before trusting a status in either system and say which system your evidence came from.
Before a ticket moves systems, its thread summary goes into the destination as a plain-text
note — links back to the old system die when the old PSA is decommissioned, so the note must
stand alone. Notes are plain text, no markdown or emojis (apply the PSA Note Discipline skill).
```


## Related topics

- [Queue Hygiene Score](/skill-library/qa-and-closure/queue-hygiene-score.md)
- [Stale Device Cleanup](/skill-library/m365-administration/stale-device-cleanup.md)
- [Stale Doc Hygiene](/skill-library/documentation/stale-doc-hygiene.md)