This article walks an existing v1 account through the migration to v2. It is the master document — each milestone links out to the detailed setup articles where the actual work happens.

Sign in at app.giantrocketship.net. You also need to notify us of the users you want made admins in v2 — granting admin access is covered later in this article.

The migration strategy

Migration to v2 follows the calibration pattern described in Manual vs Automatic — Calibrating Your Account: move one piece of the system from manual to automatic at a time, verify it works against real tickets, then move the next. Don't try to flip everything at once.

Based on several customer migrations, this is the order that works:

1. Do basic setup. This lets Horizon begin importing data.
2. Test manual triage in v2 to get familiar.
3. Test scheduling in the Agent and Dispatch calendars.
4. Test sending booking links from the Agent and Dispatch calendars.
5. Migrate triage from v1 to v2 using a Ticket Lifecycle.
6. Migrate one form from v1 to v2 using a Form Lifecycle.
7. Migrate all remaining forms.
8. Create your teams.
9. Migrate one ticket assignment using a Ticket Lifecycle.
10. Migrate all remaining ticket assignments.
    
11. Disable v1 Ticket Callouts in Autotask.

The ten steps group into six milestones below.

Milestone 1: Basic Setup

The basic setup follows the standard New Account Setup process, with a few migration-specific notes.

Phase 1 — Onboarding Wizard

You can skip this phase. We will have already set your account up.

Reference: Phase 1 - Onboarding Wizard.

Phase 2 — Integrations

Reference: Phase 2 - Integrations.

In this phase:

• Verify the Autotask connection ported over. Our backend migration script handles the connection itself; confirm in v2 that it is present and authenticated.
• Create the new Security Level for v2 callbacks. v2 needs a dedicated security level so it can register callbacks in Autotask. See Registering Helpdesk Callbacks in Horizon.
• Install the v2 Autotask dashboard widget and ticket insight. v1 widgets do not work for v2. See Adding Horizon Autotask Widgets.
• Confirm Helpdesk, Calendar Provider, and AI integrations. Each is configured in Phase 2.
• Optionally, configure SMTP Relay. See How to Set Up SMTP Relay and Mail Sending Settings — Delivery Modes & Helpdesk Address.

Phase 3 — Initial Filters and Actions

Reference: Phase 3 - Initial Filters and Actions.

Like v1, v2 works best with preset status filters and update settings. The Admin screen walks you through it. For example, it asks what status to use for General Failure — the field v1 called Needs Help.

Granting admin access

You need to notify us of the additional users you want made admins in v2. After we grant the first admin, that admin can grant additional admin access via People → Users → edit user → Panel Access → tick Admin. Full guidance in the User Admins section of Teams, Users, and Business Hours.

Milestone 2: Get Familiar with Admin

Once setup is complete, spend time in v2 before migrating any v1 automation. The point is to confirm the system works on real tickets manually before you move things to automatic.

Reference for the Admin panel itself: New Admin Training.

Step 2 — Test manual triage

Run triage by hand on a few real tickets to confirm a triage policy is wired up and behaves the way you expect. See Understanding Triage as a Dispatcher for both the Ticket Board and Ticket Widget methods.

Step 3 — Test scheduling

Create scheduled todos in both the Agent calendar and the Dispatch calendar. Drag work around. Confirm the calendar reflects what you scheduled. See Calendar Mastery — Drag-and-Drop (agent perspective) and Calendar Mastery — Drag-and-Drop (dispatcher perspective).

Step 4 — Test sending booking links

Send a booking link to a real customer from both the Agent and Dispatch calendars. Confirm the link works, the customer's pick lands on your calendar, and the slots offered match your business hours. See Customer Self-Booking.

If something doesn't behave the way it did in v1, stop here and resolve it before moving to migration. v2 manual operation needs to be solid before any automation is migrated.

A short detour: what is a Lifecycle?

The next four milestones all use Lifecycles, so a quick definition before continuing:

A Lifecycle is a rule that says "when X happens, run Y." A Ticket Lifecycle rule fires on ticket status change — for example, "when a ticket enters the New status, run Triage and assign it." A Form Lifecycle rule fires on form submission — for example, "when the Approval form is submitted, write a note and apply a helpdesk preset."

Lifecycles are how v2 replaces v1's automation. Full coverage in Ticket and Form Lifecycles.

Milestone 3: Migrate Triage

Step 5. Build a Ticket Lifecycle rule that runs your triage policy on the appropriate status (typically New).

1. Confirm a triage policy is configured. See How to Configure a Triage Policy and Setting Up Triage.
2. In Ticket Lifecycle, create a rule:
   • Status: the helpdesk's New (or equivalent)
   • Filter: empty (catch-all)
   • Action: Triage
   • Triage Policy: the policy from step 1
3. Save.
4. Test by creating a real ticket. Confirm triage runs automatically and the field changes match what manual triage produced in milestone 2.

If the automatic results match the manual results, triage is migrated. Disable the v1 equivalent.

Milestone 4: Migrate Forms

Step 6 — Migrate one form

Pick a single low-risk form first.

1. Recreate the form in v2 if it doesn't already exist. See Custom Forms.
2. In Form Lifecycle, create a rule for that form. Add the actions you want to run on submission (add ticket note, execute helpdesk preset).
3. Save.
4. Submit the form on a real ticket. Confirm the actions fire and produce the same outcome the v1 form produced.

Step 7 — Migrate all remaining forms

Once one form is verified working, migrate the rest using the same pattern. Disable each v1 form as its v2 equivalent goes live.

Milestone 5: Create Teams

Step 8. v2's assignment policies operate on teams. Set them up before migrating ticket assignments.

See Teams, Users, and Business Hours for the full walkthrough — users, teams, business hours plans, panel access (including admin), and the recommended setup order.

You should already have admins from milestone 1; this milestone is about creating the teams that assignment policies will route to.

Milestone 6: Migrate Ticket Assignments

Step 9 — Migrate one ticket assignment

Pick a single assignment policy or routing rule from v1 — ideally one with low ticket volume.

1. Configure the v2 ticket assign policy. See Auto-Assign with Round-Robin and Auto-Assign with NextAvailable Using Floating Todos.
2. In Ticket Lifecycle, create or update the relevant status rule's action to Triage and Route (if migrating triage and routing together) or just Route (if triage is already migrated).
3. Save.
4. Test on a real ticket. Confirm the right team and the right agent get picked.
5. Disable the v1 equivalent.

Step 10 — Migrate all remaining ticket assignments

Once one assignment is verified working, migrate the rest. Watch for tickets that are now being assigned by both systems — those are the ones where the v1 equivalent didn't get disabled. Resolve before continuing.

When the migration is complete

• Every v1 triage policy has a v2 Ticket Lifecycle equivalent and the v1 version is disabled.
• Every v1 form has a v2 Form Lifecycle equivalent and the v1 version is disabled.
• Every v1 assignment rule has a v2 ticket assign policy equivalent and the v1 version is disabled.
• New tickets are auto-triaged, auto-assigned, and (where applicable) auto-acted-on by Form Lifecycles without manual intervention.
• Admins describe v2 behavior in "when X happens, Y runs" terms — not in v1 terms.

If you can do all of the above and the results match v1's behavior, the migration is complete. v1 can be turned off.

Tip: Migrate in the order above, not in parallel. The whole strategy depends on calibrating one piece at a time so you can isolate problems. If you migrate triage and assignment simultaneously and the wrong agent picks up a ticket, you don't know whether triage misclassified it or assignment misrouted it. One at a time, verified, then next.

Tip: Keep both v1 and v2 running until each migrated piece has been verified. Disable v1 only after the v2 equivalent has handled real tickets correctly. The cost of a brief overlap is duplicate automation; the cost of premature cutover is broken automation with no rollback.

Tip: If a v2 result doesn't match v1's behavior on a real ticket, that's not a v2 bug by default — it's usually a configuration difference between the v1 policy and the v2 equivalent. Investigate the policy first, escalate to support second.