Tally on Cloud: a buyer's guide for finance teams

The software does not change. Tally on Cloud is the same TallyPrime you already run — the same vouchers, the same reports, the same TDL customisations — installed on a Windows server in a datacenter instead of on a desktop under someone's desk. What changes is everything around the software: where the data lives, who can reach it, how it is backed up, and whose problem it is when hardware fails.

Users connect over a remote desktop session or a published application, which means the data never sits on a laptop. That single fact resolves most of the operational problems finance teams live with: the "server" machine that cannot be switched off, the data folder copied onto a pen drive before an audit, the branch office that cannot see the same books until month-end exports are emailed around.

It does not change licensing terms from Tally Solutions — you still own your Tally licence — and it does not turn Tally into a different product. Judging a provider on anything other than infrastructure quality and operational discipline is a mistake.

Reasons that hold up

• Multi-location access. Branch offices, a travelling CFO, an external CA firm — everyone works on the same live books instead of synchronising files. For any business with more than one location, this alone usually justifies the move.
• Backup reliability. A provider that backs up nightly to a second location, and tests restores, replaces the ritual of hoping someone's scheduled copy actually ran.
• Hardware independence. No single desktop is a point of failure. Upgrades, failures and office moves stop being finance-team emergencies.
• Controlled access. Centralised user accounts, session logging and the ability to revoke access instantly — instead of a shared Windows login on a machine in the accounts room.

Reasons that don't hold up

• "It will be faster." Over a good connection a hosted session is perfectly responsive, but it is not faster than a local install on a fast machine — and a poor connection will feel worse. The gain is access and reliability, not raw speed.
• "It will fix our data." Corrupted company data, a broken voucher numbering habit, or a chart of ledgers that has grown organically for a decade all move to the cloud exactly as they are. Clean-up is a separate exercise, best done before the move.
• "It replaces our accountant's discipline." Hosting changes infrastructure, not process. Cut-off dates, reconciliation habits and review cadence are still yours to enforce.

The market for hosted Tally ranges from serious datacenter operators to a reseller with a single rented server. The differences only become visible when something goes wrong — unless you ask the right questions up front. Take these in order.

1. Data residency. In which country and city does the data physically sit, and does it ever leave? For Indian finance data, an in-country answer should be the default, not an upgrade.
2. Backup frequency and tested restores. "We take backups" is not an answer. Ask how often, to where, how long they are retained — and when a restore was last tested end to end. An untested backup is a hypothesis.
3. Uptime commitment. Is there a stated uptime target in writing, and what is the remedy when it is missed? Distinguish a marketing claim from a contractual one.
4. Concurrent-user licensing. How many simultaneous sessions are included, what does each additional user cost, and does the plan align with your Tally licence (Silver vs. Gold) rather than fight it?
5. Data export rights and lock-in. Can you take a full copy of your Tally data folder at any time, in native format, without paying a release fee? If the answer is anything other than an unqualified yes, treat it as a serious warning.
6. Support hours and scope. Who answers at 7 pm on the day before a filing deadline? Does support cover only the server, or also Tally connectivity, printing and session issues?
7. Security controls. Encryption in transit, individual user accounts (never shared logins), session logging, and a clear statement of who at the provider can access your data and under what process.

Our Tally on Cloud plans are built to answer each of these questions in writing, precisely because they are the questions a finance team should be asking anyone.

Latency for remote users

Remote desktop protocols handle intermittent connections far better than opening Tally data files over a network share — that is the technical reason hosted Tally works at all. Even so, a stable broadband connection of modest speed matters more than a fast but flaky one. Any serious evaluation should include a trial from the actual locations and networks your team will use, at actual working hours.

Printing

The most common day-one complaint. Invoices and vouchers need to print on the local printer at each user's location, which requires the provider's session setup to support printer redirection properly — and someone to configure it per user. Confirm this is part of onboarding, not an afterthought.

Multi-company and multi-user setups

Group companies running several Tally companies concurrently, with different user subsets in each, map cleanly onto a hosted environment — but only if the plan's concurrent-user model matches how your team actually works at peak (typically the first week of the month and filing deadlines). Model the peak, not the average.

Add-ons and customisations

TDL customisations, invoice formats and integrations with other software generally work unchanged, because the Tally installation itself is standard. The exceptions are integrations that depend on local file paths or on another application running on the same machine — a Tally-to-billing integration on a shop-floor PC, for instance. List every integration and confirm where each one will live before the move; this is also where Tally customisation work and hosting decisions meet.

A competent migration is uneventful by design. The mechanics are simple; the discipline is in the sequencing.

1. Provision and configure. The server is set up, Tally installed, user accounts and access controls created, printing configured per user.
2. Copy and verify data. A full copy of the Tally data folders is taken and loaded on the server. Verification means opening each company, checking period books against known figures — trial balance as of the last closed month is the usual check — and confirming customisations behave.
3. Freeze and cut over. Users stop entering vouchers on the old machine at an agreed time — end of day, never mid-morning. Any final day's data is moved, and from the next morning everyone works on the server.
4. Keep the fallback. The old installation is left intact but made read-only in practice, for an agreed transition period — typically two to four weeks. If anything surfaces, the fallback exists. Once the period closes cleanly, it is retired.

Done this way, downtime is an evening, not a week. Providers who talk about week-long cutovers for a straightforward Tally move are describing their process problems, not yours.

These are three genuinely different answers to three different problems, and the right choice depends on which problem you actually have.

• Stay on-premise if you operate from one location, the machine hosting Tally is reliably managed and backed up, and nobody outside that office needs live access. Many single-site businesses are genuinely fine here — the move would solve problems they do not have.
• Move to hosted Tally if Tally fits your accounting workflow but access, backup or hardware reliability is the pain. This keeps the software your team already knows and fixes the infrastructure around it — the smallest change that solves the actual problem.
• Evaluate a broader ERP — such as Odoo or a custom build — when the limitation is Tally itself: you need integrated inventory and sales workflows, approval chains, CRM, or operational reporting beyond what accounting software is designed to do. That is a business-process decision, not a hosting decision, and it deserves its own evaluation rather than being smuggled into one.

The mistake to avoid is conflating the three. Hosting fixes access and reliability; it does not add workflow. An ERP adds workflow; it does not make access problems disappear. Decide which problem you are solving, then buy exactly that.