Skip to content
MSP Operations9 min read

The First 100 Days on a New PSA: A Survival Guide

Cory Neese·

Day one on a new PSA is both exciting and terrifying. The platform is clean. The configuration is fresh. The team is cautiously optimistic. And within 48 hours, the reality of learning a new system under production pressure starts to set in.

The first 100 days after a PSA go-live are the most critical period in the platform's lifecycle at your MSP. What happens during this window determines whether the system becomes a genuine operational backbone or just another tool your team tolerates while building workarounds on the side.

Here's how to navigate it.

Days 1–14: Survival mode

Be honest with yourself and your team: the first two weeks are going to be slow. Ticket resolution times will increase. People will spend longer on tasks that used to be automatic. Frustration will peak somewhere around day 4 or 5, when the novelty has worn off and the muscle memory for the old system is still dominant.

This is normal. Name it. Tell your team on day one: "The next two weeks will be slower. That's expected. It gets better."

The priorities during this window:

Keep tickets flowing. Nothing else matters if tickets aren't being created, assigned, worked, and closed. If a configuration issue is blocking ticket flow — routing doesn't work, email parsing isn't creating tickets, SLAs aren't calculating — that's a drop-everything priority.

Staff a help desk for the help desk. Designate one person (internal or external) as the PSA support contact for the team. Every "how do I do X in the new system?" question goes to this person. If questions go unanswered, people build workarounds. Workarounds become habits. Habits become permanent. Cut that cycle early.

Don't change the configuration. I know this sounds counterintuitive. But in the first two weeks, resist the urge to start tweaking things based on initial feedback. Early feedback is contaminated by the learning curve. A status that "doesn't make sense" on day 3 might make perfect sense by day 10 when the team has internalized the new workflow. Collect feedback. Document it. Wait.

Days 15–30: Stabilization

The team is functional. Not fast, not fully comfortable, but functional. This is when you start addressing the real configuration issues versus the perceived ones.

Review the feedback collected during the first two weeks. Sort it into three categories:

Training gaps — things the team is doing wrong because they haven't learned the right way yet. These are solved by targeted follow-up training, not configuration changes.

Configuration adjustments — things that genuinely need to change because the initial setup didn't account for a specific workflow or edge case. A status that's missing, a routing rule that needs refinement, a custom field that techs need but don't have. Make these changes now.

Feature requests — things that would be nice to have but aren't blocking anything. Log these for later. Don't clutter the stabilization window with optimization projects.

This is also when billing needs serious attention. Run the first full billing cycle on the new system with extra scrutiny. Compare every invoice against what you expect it to be. Catch discrepancies now, before they compound.

Days 31–60: Optimization

The team is comfortable with basic operations. Resolution times are recovering toward baseline. The urgent configuration issues from the first month are resolved.

Now you can start building the features that turn a basic PSA into an operational engine:

Workflow automation. During implementation, you probably set up the essential workflow rules. Now build the second tier: stale ticket alerts, automated client follow-ups, SLA escalation chains, after-hours routing. Each rule you add removes a manual process from your team's day.

Reporting. The canned reports got you through the first month. Now build the custom reports and dashboards that actually drive decisions: client profitability, tech utilization, SLA compliance trends, agreement coverage ratios. Don't try to replicate every report from the old system — take this as an opportunity to build the reports you actually need, not the ones you inherited.

Client portal refinement. If you launched with a basic portal configuration, now refine it. Customize the ticket submission form, add knowledge base articles for common issues, configure the status display so clients see meaningful information. Then actively promote portal usage to your clients.

Integration tuning. Your integrations are running but may need adjustment based on a month of real-world data. Check sync logs for recurring errors. Verify that data mappings are producing accurate results. Tighten up any integrations that were configured loosely during the initial push.

Days 61–100: Maturity

This is where the PSA starts paying dividends — if you've invested in the previous phases.

Process documentation. Document how the PSA is configured and why. Not just the technical settings — the business logic behind the configuration. "We route Priority 1 tickets directly to the senior tech team because our SLA requires 15-minute response on critical issues." Future you, and the person who replaces you someday, will thank present you.

Training refresh. Run a second round of training focused on advanced features. The team has enough context now to absorb more sophisticated capabilities — things that would have been overwhelming on day one but make sense after two months of daily use.

Metrics review. You now have two to three months of data in the new system. Pull it. Compare key metrics against the old system's baseline: average resolution time, billable utilization, billing accuracy, SLA compliance. If the numbers are improving, the migration is working. If they're flat or declining, investigate why and address the root cause.

Decommission the old system. If you've been keeping the old PSA accessible for reference, set a date to shut it down. Export any historical data you want to retain, archive it somewhere accessible, and turn off the old platform. Keeping it running creates a psychological safety net that slows adoption of the new system.

The mistakes that derail the first 100 days

Changing too much too fast. Every problem feels urgent in the first week. Most aren't. Rushing configuration changes based on day-3 feedback creates instability and erodes trust.

Insufficient training investment. A half-day training session before go-live is not enough. Budget for follow-up training at day 14 and day 60. The questions your team has after two weeks of real use are completely different from the questions they had during the initial walkthrough.

Not having a PSA point person. Someone needs to own the platform. Not as a side responsibility — as an explicit part of their role. This person fields questions, makes configuration adjustments, monitors integration health, and serves as the bridge between the team's needs and the system's capabilities.

Reverting to old habits. The shadow spreadsheets, the email workarounds, the manual processes — they need to stop. If the team is still running parallel processes in the old way, the new PSA will never become the system of record. Set a hard cutoff date for legacy processes.

Comparing to the old system. "In ConnectWise, I could..." is the most common complaint during migration, and it's usually unproductive. The new system works differently. Some things will be better, some will be different, and a few might genuinely be worse. Focus on getting proficient in the new way rather than mourning the old way.

Day 101 and beyond

If you've navigated the first 100 days well, you have a stable, configured, documented PSA with a trained team and good data quality. The hard part is behind you.

From here, the work shifts to continuous improvement: quarterly configuration reviews, ongoing automation builds, expanding reporting as data accumulates, and evolving the configuration as the business grows.

The PSA is never "done." It's a living system that needs regular attention. But the first 100 days establish the foundation that everything else builds on.


Going through a PSA transition? Book a call and let's make sure your first 100 days go smoothly.

Cory Neese

Founder & PSA Consultant at PaxRig

Cory helps MSPs get more out of their ConnectWise and HaloPSA platforms through expert configuration, migration, and automation. He founded PaxRig to bring enterprise-level PSA expertise to the MSP channel.

Need help implementing this?

Book a free discovery call and I'll walk through your specific situation.