PSA implementation and migration
Your PSA is where a support request turns into an invoice. We set one up for your business, or move you between platforms such as HaloPSA, ConnectWise and Autotask, and check your agreements and billing before you switch.
This project is about your business, not a client’s
The PSA is where your engineers spend their day, where SLAs are measured and where your monthly invoicing comes from. When it’s set up badly, the cost shows up slowly: tickets nobody saw, time nobody billed, and agreements that under-charge for months before anyone notices. So we treat it as a finance system as much as a service desk tool.
- Your engineers are the users.
They need to log a ticket and their time in the new system without hunting for the right board, status or work type.
- Your cash flow runs through it.
Agreements, rates, inclusions and prepaid balances have to arrive exactly as they were, or be corrected on purpose.
- Your service desk has to keep running.
Email, portal and alerts need a home at every point of the change, so the switch is planned as carefully as the build.
Follow one ticket from inbox to invoice
A PSA is one long chain. A migration or a new setup has to carry every link, because a break anywhere ends up as work nobody sees or time nobody bills. Here is where each link usually breaks, and what we do about it.
-
It arrives
An email to your support address, a request through the client portal, a phone call logged by hand, or an alert from your RMM.
Where it breaksMail rules still pointing at the old platform. Alerts that open a fresh ticket every time a service flaps, until engineers stop reading them.
How we handle itWe map every way work comes in, connect your RMM so alerts become tickets worth opening, and plan the intake switch as one step at cutover.
-
It gets sorted
Client and contact, ticket type, priority, and the board or queue it belongs on.
Where it breaksYears of statuses copied one-for-one, so the new board has dozens and nobody is sure which one means “waiting on the client”.
How we handle itTypes, statuses and priorities designed around how your desk works, with every old value mapped to a new one so history still reads correctly.
-
The clock starts
Response and resolution targets, business hours, public holidays, and the statuses that pause the clock.
Where it breaksAn SLA that pauses on the wrong status, or business hours on the wrong time zone for clients in another state, so reports look healthy while clients wait.
How we handle itSLA plans rebuilt from what you’ve promised clients, with hours, holidays and pause rules set per plan rather than carried over blind.
-
Work gets logged
Time entries against a work type, billable or not, at the right rate.
Where it breaksWork types that don’t line up with what agreements include, so covered work gets invoiced and extra work gets absorbed.
How we handle itA short list of work types an engineer can choose without thinking, with the agreement, not the engineer, deciding what’s billable.
-
The agreement decides
Recurring fees per user or device, prepaid hours, time and materials, project work and exclusions.
Where it breaksPrepaid hours that restart at zero, user and device counts that stop updating, end dates lost in the move.
How we handle itEach agreement rebuilt and compared with the old one: what’s included, what’s charged and what’s left on the balance.
-
It becomes an invoice
The invoice run, tax codes, and the sync to your accounting platform.
Where it breaksDuplicate customers created in accounting, tax codes that don’t match, or a month billed twice, or not at all, around the switch.
How we handle itThe accounting integration matched to the customers already there, and the cutover date chosen around your billing cycle.
What comes across, what’s rebuilt and what stays behind
A migration is the best chance you’ll get to clean up your PSA. Before anything moves, we go through it with you and decide what each kind of record deserves.
Comes across
Migrated, cleaned on the way.
- Clients, sites and contacts, with duplicates merged
- Assets, matched against what your RMM can see
- Active agreements, with their balances and end dates
- Open tickets, with their notes and time
- Ticket history, as far back as you decide
Rebuilt properly
Configured fresh in the new platform, not imported.
- Ticket types, statuses and priorities
- Boards, queues and who sees what
- SLA plans and business hours
- Workflows, automations and notifications
- Work types, rates and invoice templates
Stays behind
Agreed with you, item by item.
- Clients you no longer support
- Contacts who have left
- Devices that were retired years ago
- Statuses and custom fields nobody uses
- Workarounds for the old platform’s limits
Billing is checked before you switch
The first invoice run is where a PSA migration gets tested. We check before then.
Before cutover we put your agreements side by side, current platform against new, and work through every difference until it’s fixed or explained. User and device counts, prepaid balances, inclusions, exclusions and end dates all get compared, agreement by agreement.
Most differences come from how each platform models the same thing, and they’re easy to fix once they’re visible. The costly ones are the ones nobody notices until an invoice goes out: a balance that reset, an exclusion that turned into an inclusion.
| Line | Current | New | Result |
|---|---|---|---|
| Managed users | 24 | 24 | Matches |
| Monitored servers | 3 | 3 | Matches |
| Prepaid hours left | 7.5 h | 0 h 7.5 h | FixedBalance carried across |
| After-hours work | Billable | Included Billable | FixedExclusion restored |
| Agreement ends | 30 June | Not set 30 June | FixedEnd date restored |
Setting up your first PSA
If you’re running support from a shared mailbox, a spreadsheet and your accounting software, there’s little to migrate but a lot to decide.
The usual mistake is switching on every feature at once and burying the team in screens they don’t need yet. We set up the parts that change your day, bring your clients and contacts in from wherever they live now, and leave the rest of the platform ready for when you want it.
- One place for requestsEmail, portal and RMM alerts landing as tickets.
- Statuses that mean somethingFew enough that everyone uses them the same way.
- SLAs you can meetSet from what you offer clients.
- Time and agreements that billSo logged work flows through to invoices.
The switch, timed to your billing cycle
When you’re moving between platforms, cutover sits on a billing boundary, so one period finishes in the current platform and the next starts in the new one. Your team isn’t watching two systems for longer than they need to.
- Before cutover
The current platform keeps running
Your team works as normal while the new PSA is built, migrated and its billing compared. The last period is invoiced from the current platform.
- Cutover
One planned step
Changes made since the main migration come across. Support mailboxes, portal and RMM alerts move together.
- After cutover
The new PSA takes over
The next period bills from agreements that have already been compared. A handover session walks your team through their own boards, tickets and time entry.
What you end up with
- A PSA configured around your service desk
Boards, statuses, SLAs, work types and workflows that match how your team works.
- Your data, migrated
Clients, contacts, assets, contracts and tickets, with agreements and billing checked before cutover.
- Integrations connected
Your RMM and accounting platform, and any others in the agreed scope.
- Configuration documentation
What’s set up and why, so the next change doesn’t start with guesswork.
- A handover session with your team
On your own boards and tickets.