PSA migrations have a reputation for taking months, and it is easy to see why. A PSA touches projects, time tracking, resourcing, billing and reporting, so changing systems affects more than the software itself. There is live client work to protect, financial data to check, people to train and often years of information in the existing platform.
The process can become drawn out when the scope keeps growing. Historical data is added because someone may need it later, decisions wait on busy internal teams, and configuration or training is pushed back when client work takes priority.
Magnetic’s migrations process is designed to keep that work manageable. The full process from Discovery to go-live typically takes 8–14 weeks, including evaluation, approval, configuration and training. The migration itself is usually planned over about o ne week.
The approach is straightforward: move the information people need to keep working, keep older records available for reference, and check the key numbers before go-live.
In this guide, we’ll walk through how the migration works, what usually needs to move, where projects tend to get delayed, and how Magnetic manages the process from Discovery through to go-live.
The data transfer itself is only one part of a PSA migration. What takes time is preparing everything around it. It may start with a fairly straightforward migration plan, then discover that finance wants several years of historical data moved, another team needs to be included, an integration needs more work than expected, or the source data needs cleaning before it can be used. At the same time, the people making those decisions are usually balancing the migration with their normal responsibilities.
That is how a project that looked manageable at the start can take much longer than expected.
Company size affects the amount of work involved, but it is not always the best indicator of how quickly a migration will move. A larger firm with clean data, a well-defined scope and people available to make decisions can often progress faster than a smaller business where questions sit unresolved for days.
For that reason, it helps to establish the scope early: what needs to be available in the new system at go-live, what can remain in the old platform for reference, which reports need to match and who is responsible for signing off on each part.
Magnetic works through those questions during the early stages of migration, before the team starts moving data. It keeps the migration focused on the information needed for current work, while older projects and records can be dealt with separately where appropriate.
That preparation keeps the migration relatively contained and gives everyone a clearer idea of the work involved before the final cutover.
Every migration is slightly different, but the work generally follows seven stages. Having that structure up front makes it easier to see what needs to happen, who must be involved,, and what must be agreed upon before the migration moves forward.
We start by looking at how the business works today. That covers the practical setup in the current PSA - workflows, project structures, billing, resourcing, integrations, and reporting - as well as the areas that are creating problems.
We’ll also look at what needs to move into Magnetic and which existing processes are worth keeping. Firms that have used the same PSA for years often have workflows shaped by that system’s limitations, so this is a good point to decide what should stay and what could be simplified.
Discovery typically covers:
Making these decisions early gives the rest of the migration a clearer scope.
The demo is built around what came out of Discovery, so the team can see how its own workflows would work in Magnetic.
Finance might focus more on billing and reporting, while project and operations teams want to see project management, resourcing, and time tracking. The goal is to make the future setup tangible before anyone commits to changing systems, rather than expecting decisions from a standard product tour.
Once the requirements and proposed setup are clear, we put the migration scope in writing. This covers the timeline, deliverables, responsibilities, and pricing, so everyone knows what has been agreed before configuration starts.
Requirements sometimes change once a project starts. A new integration might arise, another team may need inclusion, or someone may want additional historical data moved. These changes can be accommodated but must be discussed as part of the scope to clarify their impact on the project.
The next stage is configuring Magnetic based on the agreed setup. Depending on the business, this may include:
This is also a good time to clean up processes that have become unnecessarily complicated. There is little value in carrying an old workaround into a new system just because it has always been done that way.
See resource planning in Magnetic →
Training takes place before go-live and is organised around the people who will actually use the system. Finance, project management, operations, and leadership use different parts of a PSA, so sessions are tailored accordingly. Follow-up resources and support are also available, which helps once people start applying what they learned to their projects, reports, and billing.
Once the setup has been agreed, the platform has been configured, and the data has been checked, the migration can take place.
The data moved depends on the business but can include active clients, open projects, contacts, users, time, expenses, and financial records linked to current work. The migration scope is agreed upon beforehand, so the team knows what will be available in Magnetic and what will remain archived in the previous system.
We cover that distinction in more detail below, because deciding what needs to move is one of the biggest factors in keeping a migration manageable.
Go-live is when the team starts using Magnetic as its working PSA. When finance is involved, the cutover is usually planned around month-end so reporting and billing move at a sensible point in the finance cycle.
The migration and implementation team stays involved after that. Hypercare runs through the first reporting cycle, typically for at least four weeks, so support is available while teams work through their first live projects, invoices, and reports in Magnetic.
That period is useful because the questions people ask after a week of real use are often quite different from the questions they ask during training.
You don’t need to move everything from your old PSA into the new one. Most firms have years of closed projects, old invoices, time records, and reports in their current system. You may need to look at that information occasionally, but you don’t need all of it in Magnetic from day one.
The priority is the work your team is using now.
This can include:
In other words, the information your team needs to carry on working after the switch.
Older information can stay where it is or be exported for reference.
That usually includes:
You still have access to the history; it doesn’t all need to be moved before you go live.
Some firms keep an admin license for their old PSA for a period of time so they can look up historical records when needed.
Keeping the migration focused on current work means less data to clean, check, and move and less work standing between your team and go-live.
Before you switch over, make sure the numbers in Magnetic line up with those your team already relies on.
That means validating:
For finance teams, this is where confidence in the new system is won or lost. If your current PSA says WIP is £250,000 and Magnetic says £243,000, no one will care that the new reporting looks better until they understand why the figures differ.
Those checks are easier to do before cutover while both systems are available. The migration and implementation team can then trace any differences back to the source.
Most problems during a PSA migration are fairly practical. They tend to come from the condition of the data, the amount you’re trying to move, how much time the internal team has to devote to the project, and whether decisions are made early enough.
If the data in your current PSA is messy, some of that will need sorting out before it moves. Duplicate clients, old users, inconsistent project structures and incorrect balances are all common, especially in systems that have been in place for years.
This is why the preparation stage matters. Your team needs time to review the source data, decide what remains relevant, and fix anything that could cause problems when it is brought into the new system.
It is easy for the migration scope to grow once people start reviewing the old system. A closed project from five years ago suddenly feels important because someone might need to reference it again, and the same thing happens with old invoices, time records and reports.
The more historical data you include, the more there is to clean, map and check before go-live. In many cases, keeping older records available for reference is enough, while the migration itself stays focused on the work the business is actively using.
Migration a is happening alongside normal delivery, so the people involved are usually doing it on top of their existing responsibilities. Finance still has month-end to get through, project teams still have deadlines, and operations still has a business to run.
That has to be taken into account when planning the migration. The work needs to be phased around the business rather than creating a period where teams are stuck between two systems or unable to get on with client work.
Teams need enough time to get comfortable with the new system before they are expected to use it for live work.
If training is left until the last minute, people are much more likely to fall back on familiar habits once the system goes live. That can mean keeping separate spreadsheets, using the old platform for longer than planned, or handling the same process differently across teams.
Role-based training ahead of go-live gives people a chance to understand the parts of the system they will actually use and ask questions before those questions affect real projects or billing.
Migration projects often pick up extra requirements once they are underway. A new report gets added, another integration becomes important, or a team that was not included in the original plan needs to be brought in.
None of those requests is unusual, but they do affect the amount of work involved. If changes keep being added without revisiting the scope or timeline, the project can run well beyond the original plan.
Keeping those changes documented and agreed as they come up makes it much easier to see what is genuinely required for go-live and what can wait until afterward.
The problems above are common, so the migration process must address them before go-live instead of relying on the team to fix them afterward.
Magnetic’s approach combines a clear migration scope, structured data mapping, role-based training and support through the first reporting cycle. The migration is partner-led, but your team stays involved in the decisions that require business context and sign-off.
Before anything is migrated, the source data needs to be mapped and checked. Magnetic uses field-mapping templates and migration data templates to define where information from the old PSA will sit in the new system.
Your team remains responsible for cleaning and validating data because you know which clients, jobs, and records are current and which are no longer relevant. The migration partner handles the migration alongside you instead of leaving your team to manage the technical details alone.
Not every record needs to be moved before the team can start using Magnetic.
Open projects, active contacts, current transactions, and the information needed to keep work moving can be migrated, while closed projects and older records remain available for reference.
This keeps the data needing cleaning manageable and avoids delaying go-live for information the team rarely uses.
Migration happens while client work continues, so the process must fit around the people involved rather than become another project for them to manage on the side.
Magnetic’s migration is partner-led, with the migration work coordinated alongside your team so day-to-day delivery can continue.
Your team still makes the decisions only it can make. There is a clear process and someone responsible for moving it forward.
Training is done before go-live and tailored to the roles using the system. Finance, operations, and delivery teams each need different parts of Magnetic, so there is little value in giving everyone the same generic walkthrough.
Recorded sessions are also available afterward, and support continues through the hypercare period once the team starts using Magnetic for real projects, billing, and reporting.
Migration requirements often change once migration and implementation is underway. A new report might be needed, another integration may come into scope, or a team that was not included originally might need to be added.
Magnetic uses milestone gates, with scope changes documented and agreed before the extra work is taken on.
This gives everyone a clear view of what the migration includes and what any new request means for the timeline.
Hoorah Digital had grown into a more complex agency operating across multiple offices, service lines, and embedded client teams. Its existing setup no longer provided the flexibility or visibility the business needed as the model evolved.
The team wanted a platform that could support different ways of working across the agency, provide leadership a single view of projects and resources, and be simple enough for internal teams and embedded client stakeholders to use.
That led them to Magnetic.
Because the setup was more complex, the rollout was phased instead of moving everyone at once. Hoorah mapped existing workflows and data, configured Magnetic for different parts of the business, migrated client and historical records, ran both systems in parallel before cutover, and trained teams as they transitioned.
The result was one platform across the agency and its embedded teams, with better visibility and a setup that could support the way the business had grown.
PSA migrations tend to take long when the project expands. Historical data is added because someone might need it later. New requirements appear halfway through, and training or validation is squeezed into everyone’s day jobs.
A good migration plan keeps those decisions under control. It clearly defines what must be ready for go-live, what can wait until afterwards, and who is responsible for each part of the work. This keeps the project moving without cutting corners on what matters, especially data checks, reporting, and training.
For most firms, the biggest time saving comes from discipline about scope. Move the information people need to work, keep older records available for reference, and address questions early instead of carrying them into the final week.
Every business has a different setup, so the best way to understand the work involved is to look at your current system, data, integrations, and reporting requirements.
That is what we cover in a Magnetic Discovery call. From there, we can put together a written proposal covering the migration scope, expected timeline, deliverables and pricing.
Start a free trial and see Magnetic with your own projects. No credit card required.
.svg){kind=small}
Most migrations take 8 to 14 weeks from Discovery to go-live, depending on size and complexity. Smaller, simpler firms complete the process in about 8 weeks. Larger, multi-office firms with more service lines or billing models usually take 14 to 16 weeks because there is more to configure and more teams to train.
Open projects and active work migrate in full. Closed projects, historical invoices, and legacy reports are preserved for reference and remain exportable, since they don't need to sit in the new system for daily operations to run.
Active projects continue without interruption throughout the process. Old and new systems can run in parallel until the team is confident to cut over. Go-live is usually timed to a month-end boundary to avoid splitting a billing period.
Equivalent reports are rebuilt and reconciled with current numbers before cutover, so trend lines remain comparable rather than resetting to zero on the day you go live.
A common misconception is that the customer must export and re-map their own data. In a properly run migrations, a dedicated partner leads the migration end-to-end alongside the customer's team. The customer validates and signs off instead of doing the technical mapping themselves.
Hypercare support continues through the first full reporting cycle after go-live, typically four or more weeks, with a dedicated contact and an escalation path, not just documentation to work through on your own.
Magnetic is an all-in-one workflow management platform designed and built for professional services firms.
.svg){kind=icon}
.webp)
