A PSA rollout touches CRM data, active projects, unbilled time, and every open invoice at once, which is exactly why treating it like a weekend software swap backfires. Firms that get a smooth go-live almost always run the same four phases in the same order: configure before you migrate, migrate before you pilot, and pilot before you ask the whole firm to switch. Skip a phase and you find out about it three weeks later, in the middle of a billing cycle, with two systems half-updated and nobody sure which one is correct. This guide lays out that sequence in enough detail to plan an actual go-live date.
In this guide
The four phases of a PSA rollout, in order Data migration: what to move first, and what to leave behind Running a pilot before you go firm-wide Getting adoption to stick after go-live Frequently asked questions
The Four Phases of a PSA Rollout, In Order
Every successful implementation we've seen breaks into the same four phases, and the order matters more than the calendar time each one takes. Configuration comes first: set up your service lines, project templates, rate cards, and approval chains before a single record gets imported, because migrating data into a system that isn't configured yet just means redoing the mapping later. Migration comes second, moving live clients, open projects, and unbilled time into the new system. Piloting comes third, running one team on the new platform while the rest of the firm keeps working as usual. Firm-wide go-live is last, and it should feel anticlimactic by the time you get there, because the pilot already found the surprises.
If you haven't finished evaluating what modules a PSA actually needs to cover, CRM, projects, time, and invoicing working off one data model rather than four disconnected tools, it's worth reviewing what the category includes before you configure anything. Our guide to what PSA software is covers that ground, and the features page shows how those modules connect to each other inside Autovella specifically.
A realistic timeline for a firm under 100 people is four to six weeks from kickoff to full cutover: about a week for configuration, a few days for migration, two to three weeks for the pilot, then go-live. Firms with multiple offices, complex approval chains, or unusual billing arrangements should budget six to ten weeks, mostly because pilot feedback and permission setup take longer, not because any single step is technically harder.
Data Migration: What to Move First, and What to Leave Behind
The instinct on migration day is to move everything, every client record back to 2019, every closed invoice, every timesheet from a project that wrapped two years ago. Resist it. That data rarely gets touched again once a project closes, and importing it live just adds cleanup risk to a week that already has enough moving parts. Export it and keep it accessible for audits or lookups, but don't make it part of the cutover.
- Active clients and contacts, anyone with an open project, an open deal, or an invoice awaiting payment, these need to be correct on day one
- Open projects and their remaining scope, including budgets, milestones, and assigned team members, so delivery doesn't lose continuity mid-engagement
- Unbilled time and expenses, every hour logged against an open project that hasn't been invoiced yet, since this becomes real revenue the moment the new system goes live
- Unpaid invoices and their aging, so accounts receivable doesn't lose visibility on who owes what, and collections follow-ups don't reset to zero
- Open pipeline deals, proposals and quotes currently in play, so sales doesn't have to re-enter a live deal it's mid-negotiation on
Everything else, closed-won deals from three years ago, fully paid invoices, timesheets on projects that ended before this quarter, can wait in an export. Bringing that in later, once the live data is stable, is far lower risk than trying to reconcile it during cutover week.
Running a Pilot Before You Go Firm-Wide
Pick one team, ideally a project type that's representative of how most of the firm works, and run it on the new system for two to three weeks before anyone else switches. Keep the rest of the firm on the old tool during that window. This isn't about being cautious for its own sake, it's about controlling where the first bugs show up. A missing approval step, a rate card that's mapped wrong, a permission that locks a project manager out of their own project, these things happen in almost every rollout. The only question is whether they happen to one team you're watching closely, or to the whole firm in the middle of a billing cycle.
The single biggest reason PSA rollouts stall is skipping the pilot. Firms that cut over everyone on day one discover their configuration gaps at the worst possible time, when adoption is most fragile and everyone has a reason to blame the new tool instead of the setup. A pilot turns those same issues into a fixable punch list instead of a firm-wide fire drill.
During the pilot, ask the pilot team to log time and update project status in the new system only, not both systems in parallel, otherwise you learn nothing about whether the new workflow actually holds up under real use. Collect specific feedback: where did someone get stuck, which report did they go looking for and not find, which approval took longer than it used to. Fix what's fixable before extending to the next team.
Getting Adoption to Stick After Go-Live
The rollout isn't done when everyone has a login, it's done when everyone has stopped opening the old tool out of habit. Three things determine whether that actually happens. First, name a champion on each team, someone whose job for the first month includes answering "how do I do X in the new system" before that question turns into someone quietly falling back to a spreadsheet. Second, set a hard sunset date for the old tool and stick to it, running two systems in parallel indefinitely just gives people permission to use whichever one is more familiar. Third, connect time entry to invoicing from day one, so the pain of not logging hours shows up immediately as a delayed invoice rather than as an abstract compliance ask.
Team size and billing complexity should also shape which plan tier you land on, a five-person studio and a 150-person consultancy with multiple approval layers don't need the same setup, and it's worth checking the pricing page against your actual headcount and rollout scope before you lock in a configuration you'll want to change in month two. Adoption is easier when the plan already matches how the firm actually operates, rather than forcing a smaller or larger footprint than the team needs.
Plan your rollout with someone who's run this before
Get a live walkthrough of how Autovella sequences migration, piloting, and go-live for teams your size.
Frequently asked
For a firm under 100 people, a realistic timeline is four to six weeks from kickoff to full go-live: about a week for configuration and setup, a few days for data migration, two to three weeks running a pilot with one team, then a firm-wide cutover. Larger or multi-office firms with more complex approval chains or billing rules should plan for six to ten weeks, mostly because pilot feedback and permission setup take longer, not because the software itself is harder to configure.
Migrate what's still open or still owed: active clients, open projects, unbilled time, and unpaid invoices. Leave closed projects and fully paid invoices from years ago in an export or your old system rather than migrating them live, since that data rarely gets touched again and importing it just adds risk and cleanup time to the rollout without changing how the new system runs day to day.
Skipping the pilot and cutting over the entire firm on day one. Without a two- to three-week pilot on one team, the first bugs, confusing permissions, or missing approval steps get discovered by everyone at once, right when adoption is most fragile. A small pilot surfaces those issues while the blast radius is one team, not the whole firm mid-invoice-cycle.