MIS Dashboard after Accounting Software Migration: How to rebuild

An MIS dashboard after accounting software migration usually breaks in the same month the new ledger goes live. The data has moved, but the ledger codes, cost centres, period locks and connectors that fed every tile have changed underneath it. Indian companies also carry a statutory layer on top: the audit trail and edit log rules under the Companies (Accounts) Rules, 2014, plus GST and income tax record retention that outlive the old software. This article covers the reporting side of the switch, from the bridge between two ledgers to restating comparatives and the checks that let a board trust the first post-migration pack.

How do you rebuild an MIS dashboard after accounting software migration?

Freeze the old ledger at a single cutover date, map every old account and cost centre to the new chart of accounts in a written bridge, restate at least 12 months of history through that bridge, run one or two closes in parallel, and only switch the dashboard source once the trial balance, GST registers and every headline tile tie to within a defined tolerance.

Why the MIS dashboard breaks after an accounting software migration

The dashboard breaks because it was built on the old ledger’s structure, not on the business. Every revenue tile, burn figure and margin line points at specific ledger names, groups or cost centres. When those are renamed, merged or recreated as tags in the new system, the formulas still run but point at nothing, or at the wrong thing.

The failure is rarely loud. Most teams see one of these patterns in the first post-migration pack:

• Revenue and gross margin drop or jump in the cutover month because one-time opening balance journals landed in P&L ledgers instead of balance sheet accounts.
• Department-level cost tiles go blank because Tally cost centres were not carried across and were rebuilt as reporting tags only for new transactions.
• Month-on-month trend lines show a step change that reflects a mapping choice, not an operating change.
• Receivable and payable ageing resets, because open invoices were imported as a single opening balance per party instead of invoice by invoice.
• GST output tax on the dashboard no longer agrees with GSTR-1 for the overlap months.

Each one is a reporting defect, not an accounting error. The books can be correct and the dashboard still wrong. That is why the rebuild needs its own plan, separate from the data migration checklist the software vendor or implementation partner signs off.

What changes in the data model when you switch ledgers

The chart of accounts remapping for MIS is the core of the work: the old and new systems store the same economics in different shapes, and the dashboard needs one stable shape across both. The table below shows where the shapes typically differ in an Indian Tally to cloud-ledger move.

Table 1: Where ledger structures diverge and what it does to MIS

The practical output of this stage is one document: an account bridge. Each row carries the old ledger name, its old group, the new account code, the new account type, the MIS line it rolls into and the cost centre or tag translation. That bridge, not the software, is what keeps the dashboard comparable.

Two design rules matter here. First, map to MIS lines, not just to new accounts. If the board pack has 18 P&L lines, every old and new account must land on exactly one of those 18. Second, keep the bridge versioned. Account additions in the new system after go-live must be added to the bridge in the same close, or the gap opens again.

Related reading: For which tiles belong on the rebuilt dashboard and how ledger choice changes the build, see Financial dashboard services for startups.

How do you keep historical comparatives after migration?

Restate history through the account bridge into a reporting layer that sits outside both ledgers. Do not rely on the new software holding prior years. Most teams import only opening balances, so the new ledger has no transaction history before cutover, and every year-on-year tile breaks for twelve months.

There are three workable approaches. The right one depends on how far back the board and investors look, and how much transaction-level history the new system can hold.

Table 2: Options for historical comparatives after a ledger switch

For most companies the first option is the right default. Export monthly trial balances from the old ledger for at least the previous 24 months, run each one through the bridge, and load the results into the same reporting layer (a data warehouse, a BI model or a controlled workbook) that now reads the new ledger. The dashboard then reads one table with a source flag per month.

The second option works when the team wants trends inside the ledger itself. If it is used, post the summary journals to a separate journal type, exclude them from GST and TDS reports in the new system, and record the reason in the migration memo. A summary journal that flows into a tax report creates a reconciliation problem the auditor will find.

Whatever the route, the restated history must tie back to the audited financial statements for the last full financial year. If the restated FY 2025-26 revenue on the dashboard differs from the audited figure, the bridge has an error, or the audited numbers include post-closing adjustments that need their own row.

What does Indian law require you to keep from the old system?

The old accounting software cannot be switched off on cutover day. Three sets of rules keep it, or a compliant extract of it, alive for years.

• Books of account, Companies Act 2013: Section 128(5) requires books of account and relevant vouchers to be preserved for not less than eight financial years immediately preceding a financial year. The old ledger’s data is part of those books.
• Audit trail, Companies (Accounts) Rules, 2014: The proviso to Rule 3(1) applies to the old software for every month it held the books, and the auditor reports under Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014 on whether that audit trail has been preserved for the retention period. A trial balance export does not carry the edit log, so archive the old system’s edit log before the licence lapses. What the rule requires of the new software is covered in Financial dashboard services for startups.
• Daily backup in India: Rule 3(5) of the Companies (Accounts) Rules, 2014, as amended by the Companies (Accounts) Fourth Amendment Rules, 2022 (effective 05/08/2022), requires electronic books to be backed up daily on servers physically located in India. Confirm the new cloud ledger’s data residency before go-live, not after.
• GST records: Section 36 of the Central Goods and Services Tax Act, 2017 requires accounts and records to be retained until 72 months from the due date of the annual return for the year they relate to. Overlap months in which returns were filed from the old system need their source data kept accessible.
• Income tax: Books for tax years from 01/04/2026 fall under the books of account provisions of the Income-tax Act, 2025, and earlier years under Section 44AA of the Income-tax Act, 1961 read with Rule 6F.

Whatever the cutover date, the dashboard should carry the cutover date visibly, so any reader can see which system produced which month.

Related reading: If the migration is happening while you prepare for a fundraise or diligence, MIS reconciliation before due diligence covers the tie-outs investors test first.

The parallel run reconciliation: proving the new dashboard is right

A parallel run reconciliation means closing at least one month, ideally two, in both systems and comparing the outputs line by line before the dashboard switches source. It is the only evidence a board or auditor can rely on that the new numbers are the same business as the old ones.

Run these checks in order. Each one depends on the one before it.

1. Trial balance tie-out at cutover: The closing trial balance in the old ledger equals the opening trial balance in the new one, account by account through the bridge, to the rupee.
2. Open items tie-out: Customer and vendor open invoices in the new system total to the debtor and creditor control balances, party by party.
3. Tax register tie-out: GST output and input for the parallel months agree between both systems and with GSTR-1 and GSTR-3B as filed. TDS deducted agrees with the quarterly return.
4. Bank tie-out: Every bank account reconciles in the new system for each parallel month.
5. MIS line tie-out: Each of the board pack’s P&L and balance sheet lines, built from the new ledger, matches the same line built from the old ledger for the parallel months.
6. Tile tie-out: Every headline dashboard tile (revenue, gross margin, EBITDA, burn, cash, runway, DSO, DPO) matches within a tolerance agreed with the CFO or finance lead in writing before the run starts.

Set the tolerance in absolute rupees and percentage, whichever is lower. A ₹50,000 difference on monthly revenue of ₹4 crore is noise; the same difference on a cash tile for a company with three months of runway is not. Every variance above tolerance gets a named cause and an owner before the switch.

Keep the reconciliation file. It is the document the auditor and, later, an investor’s diligence team will ask for when they see a cutover date in the middle of a year.

A 90-day plan for the MIS dashboard after accounting software migration

The MIS dashboard after accounting software migration is a 90-day project for most single-entity companies, running alongside the data migration rather than after it. Starting the reporting work after go-live is the main reason the first two post-migration board packs are late.

Table 3: 90-day dashboard rebuild plan around a ledger cutover

The close calendar usually changes after a move to a cloud ledger. Bank feeds and period locks can shorten the close, but only once the team stops posting back-dated entries. Update the month-end close checklist in the same cycle the dashboard switches.

Common mistakes that cost time and money

Treating the vendor’s migration sign-off as reporting sign-off. Implementation partners sign off when masters and balances load. That test does not cover MIS lines or tiles. The correct approach is a separate reporting acceptance step with its own tie-out file.

Mapping old ledgers to new accounts but not to MIS lines. The new chart of accounts often has more accounts than the old one. Without an MIS line column in the bridge, new accounts fall into an “others” bucket and margins drift month by month.

Losing cost centre history. Cost centres rebuilt as tags only apply to new transactions. Department spend before cutover disappears from the dashboard unless restated through the bridge. Budget vs actual for the year then compares a full-year budget against part-year actuals.

Switching off the old software too early. Cancelling the old licence before the retention periods end removes access to the audit trail the auditor must confirm was preserved under Rule 11(g). The cheaper route is a read-only licence or a certified archive export that includes the edit log.

Hiding the cutover from the board. A step change in a trend line with no explanation costs more credibility than the migration itself. One line in the board pack, naming the cutover date and the tie-out result, closes the question before it is asked.

Treelife practitioner note

In the MIS dashboard engagements we have run at Treelife after a ledger switch, the data migration is rarely where the problem sits. Balances usually tie on day one. The trouble starts in month three, when the first quarterly board pack asks for a year-on-year comparison and the new ledger has twelve months of nothing behind its opening balances.

The pattern we see most often is a summary-journal shortcut. Someone imports monthly totals for the prior year so that trend charts work inside the new ledger, and those journals are posted with tax codes. The new system’s GST reports then show turnover for months that were already filed from the old system. Nobody notices until the annual return reconciliation, when GSTR-9 data no longer agrees with the books the team is looking at. Keeping history in the reporting layer, not the ledger, avoids this entirely.

The second pattern is audit trail retention. The proviso to Rule 3(1) of the Companies (Accounts) Rules, 2014 covers the old software for every month it held the books. Auditors reporting under Rule 11(g) have started asking for evidence that the old edit log is still retrievable, not just the closing trial balance. A one-time archive export with the edit log, stored with the migration memo, costs a fraction of keeping a desktop licence alive for eight years.

Frequently asked questions

Q: How long should the old and new systems run in parallel?

A: One full month at minimum, two for most companies. The second month catches accruals, reversals and recurring entries that do not show in the first, and gives a clean basis for the tile tie-out.

Q: Can we migrate accounting software in the middle of a financial year?

A: Yes, but it doubles the audit trail testing for that year. The statutory auditor will test both systems under Rule 11(g) of the Companies (Audit and Auditors) Rules, 2014, and the dashboard must flag which months came from which ledger. Year start is cleaner where timing allows.

Q: How many years of history should the restated dashboard carry?

A: At least 24 months, so every year-on-year tile works from day one. Retention for statutory purposes is longer: eight financial years under Section 128(5) of the Companies Act 2013.

Q: Does the new cloud ledger need to keep data in India?

A: Yes, for companies. Rule 3(5) of the Companies (Accounts) Rules, 2014 requires a daily backup of electronic books on servers physically located in India. Confirm this in writing with the software provider before cutover.

Q: Do we need to keep the old accounting software licence?

A: Not necessarily. A read-only licence or a complete archive export works, provided it preserves the audit trail and edit log for the retention period. A trial balance export alone does not meet that test.

Q: What documents should we prepare for the statutory auditor after a migration?

A: A migration memo with the cutover date, the account bridge, the trial balance tie-out, the parallel run reconciliation and evidence of audit trail retention for the old system. Auditors ask for these when they see two systems in one year.

Q: How does the migration affect GST reconciliation?

A: Overlap months must agree between both systems and with returns as filed. Section 36 of the CGST Act, 2017 requires records to be kept for 72 months from the due date of the annual return, so source data for months filed from the old system must stay accessible.

Q: Will receivable and payable ageing survive the migration?

A: Only if open invoices are imported individually with their original dates. A single opening balance per customer resets every invoice to day zero, and DSO on the dashboard becomes meaningless for the first few months.

Q: What happens if the migration is abandoned midway?

A: The old ledger remains the book of record, and any entries posted in the new system must be brought back with a reconciliation. Keep the old ledger locked but not deleted until the new one has passed the parallel run.

Q: How should investors be told about the migration?

A: One line in the board pack and investor update naming the cutover date, the system change and the tie-out result. Investors read an unexplained step change as a data problem; an explained one as good controls.

Q: Does a migration affect the investor reporting obligations in our SHA?

A: The obligation to deliver monthly or quarterly MIS on a set date continues. If the parallel run risks a delay, agree it with the investor in writing in advance rather than missing the date.

Q: Should we migrate during a fundraise?

A: Avoid it if the data room is open. Diligence teams test the same tie-outs, and a half-finished migration adds weeks. If unavoidable, complete the parallel run before sharing MIS in the data room.

Q: Is an Indian subsidiary of a foreign parent treated differently?

A: The Indian company’s obligations under the Companies Act and CGST Act are the same. The added step is mapping to the parent’s group reporting pack, which needs its own bridge column.

Q: Can we use the migration to change the MIS format?

A: Yes, but not in the same month. Change one thing at a time: switch the source first with the old format, then redesign once the numbers are trusted.

Conclusion

A clean MIS dashboard after accounting software migration comes from treating reporting as its own workstream: a versioned account bridge, history restated outside the ledger, a two-month parallel run with written tolerances, and the old audit trail retained for the full statutory period. Done in that order, the first board pack from the new system arrives on time and reads as the same business.

About the Author

Share

• Link copied to clipboard!
  https://treelife.in/finance/mis-dashboard-after-accounting-software-migration/
  
• 
• 
• 
• 

Treelife

Treelife Team | support@treelife.in

We are a legal and finance firm with a deep focus on the startup ecosystem. We offer a wide range of services, including Virtual CFO, Legal Support, Tax & Regulatory, and Global Expansion assistance.

Our goal at Treelife is to provide you with peace of mind and ease in business.

Reviewed By

Jitesh Agarwal

Founder

Leads VCFO, finance, tax, and regulatory functions at Treelife. Advises on GIFT City structuring and strategic financial decisions for startups and scale-ups.

Priya Kapasi Shah

Associate Partner | Tax & Regulatory

Heads Financial Advisory at Treelife, specialising in investment structuring, cross-border transactions, AIF setups, and tax and regulatory advisory.