3 min read
How to Run Old and New Systems in Parallel
When you move to a new program, keeping the old one open for a while seems sensible: your team gets used to the change, past records stay available, and you can go back if something goes wrong. But if you start updating the same booking and payment in both programs, you will soon have duplicate records, balances that do not match and arguments about which one is right.
A fictional example
The fictional Pera Studio opens its new calendar on a Monday and keeps the old program available for another two weeks. The front desk marks a member's cancellation in the old program, the instructor in the new one. The next day two bookings appear at the same time. In the end, the team picks a single source for the calendar and uses the old program only to look up past records.
Which job happens in which program
First choose a single source for each job: bookings, payments, class pack balances and client communication. For example, new bookings are made in the new program, while past sessions are only viewed in the old one. Make a separate decision for payments and pack balances. If the same information can be changed in two places, do not start recording in both programs until you have written down who resolves conflicts and how.
If you can, switch off editing rights in the old program. Leaving read-only access stops your team from entering records there out of habit.
If double entry cannot be avoided
Some work may have to go into both programs for a short time. In that case, set the order in advance: which program gets the record first, who checks the second one and when, and what happens if one side fails? A "we'll enter it later" approach leaves missing and duplicate records invisible.
Do a short count every day: the number of bookings in both programs, the day's payment total and the balances of a few randomly chosen members. If there is a difference, do not quietly copy from one program to the other. Put the difference on a list and have its owner resolve it.
Pilot group and training
Instead of moving everyone on the same day, you can start with a small group. The group should represent your real work: if you choose only one instructor or only morning classes, edge cases will not show up. When training your team, use sample records instead of real client information where you can. If you do not need to move client data into a second program just for training, do not.
Copying client information from one program to another provider's program is also a data transfer. The Turkish data protection authority's explanation of domestic transfers sets out that transferring personal data to others is subject to specific conditions. Talk this through with your adviser separately from your technical migration plan.
An end date and a stop rule
The parallel period should have a start and an end date. An old program left open indefinitely keeps being used without anyone noticing. Also write down in advance what would stop the transition: overlapping bookings at the same time, a payment total difference above a set limit, a record written to the wrong person or a cancellation that does not show up. If one of these happens, it should be clear who stops new entries and who informs the team.
Checklist
- Is there a single source program for each job?
- Have editing rights been switched off in the old program?
- If double entry is needed, are the order and the person checking it clear?
- Who does the daily count?
- Does the parallel period have an end date?
- Are the stop rule and the steps to roll back written down?
This article is general information and not legal advice.