Tally Prime 7.0 in a Multi User Office Update the Server and Every Client Together
One person updating Tally is a small job. Ten people on one company is a coordination job — and the version gap between machines is where multi-user updates actually fail.
✍️ Technical Anshu🧾 TallyPrime 6.1 to 7.0⏱️ 9 minute read
🎥 Watch the complete update on screen in the video — every click, step by step
In a multi-user setup, the company data lives on one machine — the server — and every staff member's TallyPrime connects to it. The release on each screen and the format of the shared data must agree. After the server migrates the company to 7.0, that data belongs to 7.0, and Tally's own documentation is blunt about the other side: saving a transaction from the earlier release in migrated data raises an error and closes the application. So the update has to move the whole office at once.
Multi-user update — the order that works
1. Announce the window (after office hours)
2. All users save work and CLOSE TallyPrime
3. Backup taken on the SERVER
4. Server updated to 7.0, company opened + migrated
5. Numbers verified on the server
6. Every CLIENT updated to 7.0
7. Old 6.1 shortcuts deleted from desktops
8. Team resumes — in 7.0, everywhere
Write this order on the office notice board. Most multi-user update failures are just step 6 or 7 skipped.
1
Pick the Window and Announce It Like a Holiday
Choose a slot when billing can truly stop — after closing, or a weekend morning. Tell the staff the day before: Tally will be closed from this time, finish your pending vouchers before it, and do not open Tally "just to check" during the window. Half of multi-user update chaos is one person quietly working in the old version while everyone else updates.
2
On the Server: Backup, Update, Migrate, Verify
Confirm every client has closed TallyPrime — a company open somewhere cannot be treated as at rest
On the server, take the backup with Alt + Y (Data) → Backup, and copy the data folder to another machine or disk
Check the office licence and TSS on the server (Help → About) — in a Gold setup the licence lives here, and this is where reactivation, if asked, is done
Install 7.0 over the existing installation on the server, same edition as today
Open each main company, accept migration with a backup before it, and compare the trial balance with the figures noted before the update
3
Then Update Every Client — No Exceptions, No Stragglers
With the data migrated, a client still running 6.1 is not merely old — it is locked out of real work, and its attempts to save will end in errors. Walk the floor (or the remote sessions) and update every machine: billing, dispatch, the manager's laptop, the rarely used PC near the printer. That last one is the one that gets forgotten and produces Monday's first support call. Finish by deleting old 6.1 shortcuts so nobody launches the past by habit.
4
Branches and Synchronisation: Same Release Everywhere
If your office synchronises data between locations — head office and branch — plan every location into the same update window, or update them in a tight sequence before the next sync. Synchronisation expects the participating installations to be on compatible releases, and a branch still on 6.1 cannot exchange data properly with migrated 7.0 data. One phone call to the branch before you start is worth a week of mismatched books.
5
Open for Business Only After a Full Round Trip
From one client, open the company, enter a small test voucher, save it
From a second client, confirm the same voucher is visible
Print one invoice and one report from a client machine — printer mappings are per-machine and love to surprise
Then announce: Tally is open, version 7.0, old shortcuts are deleted
🔴 The multi-user rule: the release is a property of the office, not of one PC. Server first, data migrated once, every client on the same release, old shortcuts gone. An office that updates "one computer today, the rest someday" has not updated — it has scheduled an argument between its own machines.
🎥 See the Full Update in the Video
The complete TallyPrime 6.1 to 7.0 update, done live on screen — backup, installation, migration and licence check included.
Can some staff keep using 6.1 while others move to 7.0?
Not on the same company. Once the shared data is migrated to 7.0, the earlier release cannot save transactions in it — TallyPrime shows an error and closes. Every machine that touches that company must be on 7.0.
Which machine should be updated first in a multi-user office?
The server — the machine that holds the company data and the Gold licence. Back it up, update it, migrate and verify the companies there, and only then update each client machine to the same release.
Our branch office syncs data with us. When should they update?
In the same planned window, or immediately after you and before the next synchronisation. Call them before you begin: synchronisation between mismatched releases is exactly how head-office and branch books drift apart.
This guide is based on the Technical Anshu TallyPrime update video • Stuck on a step? Ask in the video comments — you will get a reply 🙏