A software implementation plan is a short document that names who moves your team to a new tool, what data moves, and on which dates. For a helpdesk it covers the support inbox, users, clients, billing, a pilot, the cutover day, a rollback procedure, and a review at day 30.
Below: an implementation plan template to copy or download, an example schedule, and a filled-in plan for a five-technician MSP. It comes from the team behind SherpaDesk, a helpdesk and professional services automation (PSA) tool a small IT team can run alone. It starts where choosing a tool ends; for that step, see Help Desk Software Requirements.
Key takeaways
What is an implementation plan? It's the document that turns a decision into dated work: tasks, owners, deadlines, and the check that closes each stage. A project plan covers the whole project, from goals and budget to schedule. An implementation plan is its working part: who does what on which day, reviewed every week.
Implementation plan guides often group the parts into five components:
For a helpdesk, implementation is mostly setup and habits. Email forwards, users sign in, rates arrive intact, and time gets logged from day one. A helpdesk implementation plan puts owners and dates on each of those.
During an implementation, your team learns the new tool while clients keep calling, so training, data entry, and support compete for the same hours. One r/msp member has never seen a PSA switch bring anything but "immediate negative impact and then a shift back to status quo after 6-12 months." That's one person's experience, but it's reason enough to name who covers the queue.
Your implementation plan lists workflows too: how a ticket arrives, who gets it, and how its time reaches an invoice. Users who email, text, or call a technician directly will keep doing it. Your implementation plan should catch those side channels, not pretend they'll stop.
Nine sections of the implementation plan. Sections 2 to 7 close with a "pass when" check, and every action carries an owner, a due date, and a result.
Helpdesk implementation planHELPDESK IMPLEMENTATION PLAN TEMPLATE
Review this implementation plan every Friday. A failed
"pass when" check moves the next date.
New tool: [helpdesk]
Replaces: [old tool, shared inbox, spreadsheet]
Owner: [one name who decides]
Backup owner: [one name]
Approves cutover: [one name]
Plan approved: [date]
Go-live date: [date]
Old tool read-only from: [date]
Support contact after launch: [name, phone, email]
Feedback route: [where users report problems]
Every action: [task] - owner: [name] - due: [date] - result: [ ]
1. GOAL, SCOPE, AND BUDGET
Done means: [every request is a ticket, time is logged on
tickets, invoices come from the new tool]
Targets: [your numbers] - baseline period: [dates]
In scope now: [email, portal, users, clients, time, billing]
Later, after day 30: [items you will not touch yet]
Budget: licenses [$ per month], setup and training
[hours], migration or setup help [$ or none], other fees
[$ or none]
OK to store client records in the new tool: [who, date]
Queue cover during setup and training: [name, dates]
2. DATA TO MOVE
[data set] - source: [ ] - owner: [ ] - check: [sample]
Before import: [duplicates removed, old fields mapped to new]
Knowledge base: [articles to move, the rest archived]
Open tickets in the old tool: [close by date, or move]
Ticket history: [import, read-only archive, or none]
Pass when: [sampled records match the source]
3. SET UP (production address not switched yet)
Pilot address: [address] - forwards to: [new tool]
Outside test: [ticket created, reply received, date]
Routing test: [right person or group]
Sign-in test: [user, date, result]
Visibility test: [users see only their own tickets]
Pass when: [all four tests pass]
4. DATA AND BILLING
Imports checked: [owner, date]
Billing test: [one ticket's time to client, contract,
prepaid balance, invoice, accounting; same result in the
old and new method]
Billing boundary: [old method through date, new tool from
date]
Pass when: [billing test results match]
5. TRAINING (before the pilot)
Trainer: [name] - technicians: [date] - queue cover: [name]
Pilot users or clients: [notice and how-to sent on date]
Pass when: [each technician alone creates, assigns, logs
time on, and closes a test ticket]
6. PILOT
Pilot group: [technicians, clients or teams; on a
two-person team: 1 technician, 1 client]
Pilot route: [pilot address] - everyone else stays on:
[old route]
Runs: [start date] to [end date]
Pilot work billed in: [old method or new tool, not both]
Watch daily: [backlog, response times, sign-in failures]
Stop if: [backlog or response time passes your limit]
Pass when: [every request is a ticket with the right
owner and time logged]
Exceptions: [issue] - owner: [ ] - fixed by: [date]
7. CUTOVER
Approved by: [name, date]
Notice to all users or clients: [date]
Before each client moves: [balances and unbilled time
refreshed, changes since the test import reconciled] -
owner: [ ] - cut-off time: [ ]
Production switch: [support address forward moved from
old tool to new tool, date and time]
Old tool: [read-only from time, export saved to location]
Production check: [email ticket, reply received, portal
ticket from an ordinary user]
Pass when: [production check passes]
Rollback trigger: [outside test through the production
route makes no ticket within minutes you choose]
Rollback decision: [name]
Rollback steps: [forward back, reopen the old tool, tell
everyone]
Reconcile: [copy tickets, replies, and time entries made
since cutover into the old tool]
8. RISKS
[risk] - [high, medium, low] - [response] - owner: [ ]
9. DAY 30 REVIEW
Requests that skipped the helpdesk: [count] - target: [ ]
Closed tickets with time logged: [ ] of [ ] - target: [ ]
First invoice run vs old method: [match, or gaps]
Backlog and response times vs baseline: [ ]
Fixes: [issue] - owner: [ ] - due: [ ]
Old process retired on: [date]
Archive searchable, checked by: [name, date]
Subscription canceled: [date, after fixes and archive check]
Fill the header and section 1 before the implementation starts. One r/msp member put the order plainly: "FIRST flesh out everything about their business from ticket reception to closure and all steps between." Then decide:
This implementation process follows Copperline IT's four-week schedule. Failed checks, staff on leave, imports that don't reconcile, or integration work move the date.
Move only your most-used fixes to a knowledge base; see How To Create A Knowledge Base. Get approval to store client records in the new tool before you test with them, and name who covers the queue.
Leave the production support address alone. Forward a separate pilot address to the new tool and test from a mailbox outside your company. The test passes only when the ticket appears and your reply reaches that mailbox.
Microsoft 365 can block automatic external forwarding by default. A blocked forward bounces with error 5.7.520. The Email Ticketing System Guide covers forwarding.
Import and verify each data set. Run one ticket's time through both methods with the same inputs, from client to accounting, and set the billing boundary for each client.
Train technicians while someone covers the queue. Then two or three technicians and one or two clients use the pilot address; everyone else stays on the old route. Bill pilot work in one place, and watch backlog, response times, and sign-in failures daily. Stop the pilot if backlog or response time passes the limit you set.
Close or move the old tool's open tickets. Before each client moves, refresh prepaid balances and unbilled time, reconcile changes since the test import, and record the owner and cut-off time.
The approver named in the implementation plan signs off, the notice goes out, and you move the production forward at a set time. Check production: an email ticket, a reply that comes back, and a portal ticket from an ordinary user.
If an outside test makes no ticket within your chosen minutes, the named person decides on rollback. Rollback means forwarding back, reopening the old tool, and copying over tickets, replies, and time entries made since cutover.
Run the section 9 counts of the implementation plan against your targets and give every miss an owner and a date. Retire the old process now. Cancel the subscription only after the fixes are done and a searchable archive is verified.
Cutover is the moment in an implementation when work moves to the new tool. Pick the approach by how many intake routes, client groups, and billing types you run.
| Approach | How it works | Fits | Main risk | What the plan needs |
|---|---|---|---|---|
| Direct cutover | Everyone switches at one time | One intake route, one client group, simple billing | A problem hits every client at once | An outside test and a written rollback |
| Parallel run | Live tickets in one tool; test cases repeated in the other | Checking billing or routing | Live work logged in both | Results compared before cutover |
| Phased | One client group or department at a time | Groups or buildings with their own intake | Two tools open for weeks | A dated order of groups |
| Pilot, then direct cutover | A small group on a pilot address, then everyone | Mixed clients and contract billing on one queue | A pilot with no end date | Pilot dates and a "pass when" |
Whichever you pick, the implementation plan keeps the old tool read-only until its archive is verified.
Example: Copperline IT has five technicians and 38 small-business clients. Requests arrive in a shared Outlook inbox, and billing lives in a spreadsheet. The owner, Dana, owns the implementation plan and works tickets.
| Section | Copperline IT |
|---|---|
| Header | Owner and cutover approver: Dana. Backup: Luis. Plan approved November 13, 2026. Go-live Tuesday, December 8; inbox read-only that morning. Support contact: Luis. Feedback: a form in the how-to |
| 1. Goal, scope, budget | Targets: under 5 requests a week outside the helpdesk (baseline October 26 to November 6: 11 a week). Time on 98% of closed tickets. December invoices within $50 of the old method. Budget: licenses per quote, 30 staff hours, nothing else. Two clients' written OK to store records, November 12. Queue cover: Sam |
| 2. Data to move | 38 clients and 412 contacts, duplicates removed and fields mapped (Luis, 20-record sample matched). 25 fix notes to the knowledge base. 38 contracts and 9 prepaid blocks (Dana, all checked against October invoices). 21 open tickets closed in the inbox by December 7. No history import |
| 3. Set up, Nov 16–20 | Outside test bounced with 5.7.520; after Dana changed the forwarding setting, the November 17 retest passed. Routing, sign-in, and visibility tests passed |
| 4. Data and billing, Nov 23–27 | Billing test: one 1.5-hour ticket on a 10-hour prepaid block left 8.5 hours and the same invoice line in both methods, and the same draft invoice in accounting. No test invoice went to the client. 2 clients on an old rate, corrected. Boundary: pilot clients in the new tool from December 1, all others in the spreadsheet through December 7 |
| 5. Training | Trainer: Dana, November 30, recorded; Sam covered the queue. Each technician alone created, assigned, timed, and closed a test ticket. Pilot clients got the notice November 25 |
| 6. Pilot, Dec 1–4 | Priya and Luis with 2 clients on the pilot address, billed from the new tool only. 31 requests, all tickets with the right owner, 3 of them phoned in. All had time logged by the next morning. Stop limit (backlog over 10) not reached. Passed |
| 7. Cutover, Dec 8 | Approved by Dana December 4; notice to all clients that day. Balances and unbilled time refreshed per client by Luis, cut-off 7:00 a.m. Forward moved at 7:30 a.m. Trigger: no ticket from an outside test within 15 minutes. By 7:40, an email ticket, its reply, and a client user's portal ticket all passed |
| 8. Risks | Email bounces (high), Dana: outside tests. Wrong rates (medium), Dana: billing test. Time in the spreadsheet (medium), Luis: lock it December 8 |
| 9. Day 30, Jan 7, 2027 | 4 requests outside the helpdesk that week, texts to Dana: met. Time on 188 of 197 closed tickets (95%): missed. December invoices within $40, the gap one unlogged visit: met. Backlog 14, baseline 16. Fixes: Priya reviews the 9 tickets with each technician by January 12; Luis logs and bills the visit by January 8; Dana forwards texts into tickets. Spreadsheet billing retired; the inbox stays as the forwarding route and a searchable archive, checked by Luis |
Subscribe to the SherpaDesk Blog.
Get Tips for Running IT With a Small Team.
Loading form…
The form couldn’t load. Please try again.
Or start your free trial →SHERPADESK · FREE TRIAL
Resolve tickets.
Turn time into revenue.
Bring support tickets, billable time, and invoicing into one place. Built for small IT teams and MSPs.
After your trial, keep your first agent free forever.
SHERPADESK · LIVE DEMO
See tickets, time,
and billing work together.
Walk through ticketing, time tracking, and billing with a product specialist. See how SherpaDesk fits the way your team works.
A live walkthrough tailored to your team.
Skipping the checks. Move to the next stage of the implementation plan only after its required checks pass.
Going it alone. Ask what the vendor's implementation help costs before week 1.
Silence. Tell users what changes. Adapt this notice:
Example
Starting [date], email [support address] or use [portal link] for help. We're switching so [one-line reason]. Requests you've already sent stay open. If you can't sign in or your email bounces, call [name] at [number]. Report access, training, or billing problems at [feedback route].
With software as a service (SaaS), you use the provider's application on their cloud infrastructure. Ask the provider how restores work, how long data is kept, and how you export it.
You configure the provider's application in a browser.
You install and run the software on your own servers.
Some clients and school districts have rules about where records may live. Get that approval in section 1 of the implementation plan, before you test with real records.
Write the targets into section 1 of the implementation plan before launch, with a baseline. During the pilot and the first week after cutover, check backlog, response times, and sign-in failures daily. At day 30, count:
For definitions of the queue numbers, see Helpdesk Metrics.
How this works in SherpaDesk
You forward your support address to a SherpaDesk email dropbox, and incoming emails become tickets. Each dropbox can route to a technician or group; use a separate dropbox for the pilot. Users sync nightly from Google or Office 365 and sign in with SSO. Active Directory/LDAP setup carries an implementation fee. Clients import from QuickBooks, Xero, FreshBooks, or Excel.
A HelpDesk Migration test import of a small sample can run in under 15 minutes. Live onboarding webinars run Tuesdays at 10 AM PST, or you can get a pre-recorded version.
A helpdesk and PSA a small IT team can run alone. No contract. No implementation project: the plan above is your team's change work, not a vendor project. No dedicated admin.
Base Camp is $45 per agent per month ($40 billed annually). The first agent is free, forever, so a team of three pays $90 a month ($80 billed annually). Setup takes about 2 minutes; 14 days free, no card.
Who this isn't for
Enterprise ITSM rollouts with change advisory boards and multi-month vendor implementation projects. An r/msp member at a 150-employee MSP said of their move: "we know it'll be a half of a year to migrate." That needs a full project implementation plan. You can't install SherpaDesk on your own servers; it runs only in the cloud.
It's the dated list of tasks that moves a team from the old tool to the new one. It names who owns each task, what data moves, when users switch, how you roll back, and when you review. The Template lays out a helpdesk implementation plan section by section.
Goals and scope, owners, a timeline with milestones, resources and budget, and risks with a fallback. In the Template, goals, scope, and budget sit in section 1. Owners sit in the header and on every action, milestones in sections 2 to 7, and risks in sections 7 and 8.
For a helpdesk: plan, set up, move data, train, pilot, cut over, and review. The template runs them in that order, with a "pass when" check on each stage from data to cutover. Each stage has an owner and a date.
See the Filled-In Example: a five-technician MSP moving from a shared inbox and a billing spreadsheet in four weeks. It has an owner, a pilot address, a billing test, a timed rollback trigger, and a day-30 review that assigns fixes.
The example takes four weeks plus a 30-day review for five technicians. A failed check, staff on leave, an import that won't reconcile, or integration work moves the date. Put your own dates in the implementation plan and move them when checks fail.
Usually not. Import clients, contacts, and contracts, and keep old records as a read-only archive you've checked you can search. If your team searches history often, test a small sample import first. Search the archive once before you cancel anything.
Patrick co-founded SherpaDesk and has led it as CEO since 2013. He has worked with IT service providers since 1998, first on network projects for schools and government offices, then on the helpdesk software their technicians use every day.