There is a specific meeting we keep getting called into. A founder or CFO asks a basic question about their own business: which product line actually made money last quarter, which customers are quietly slipping, what receivables really look like this week. Nobody in the room can answer without a week's notice. The data exists. It is spread across a fifteen-year-old Tally install, a Busy instance at one branch, an old ERP a vendor half-implemented years ago, and forty Excel files named final_v3_ACTUAL.xlsx on a shared drive. Month-end reporting takes five working days of copy-paste, and when it lands, sales has one number, accounts has another, and the gap between them is never explained, only argued about.
The reflexive fix is the big one: migrate everything into a new system. A two-year program, a steering committee, a budget that makes everyone nervous. We run a different play. It puts the first dashboard leadership actually trusts on a screen in roughly six weeks, and nobody has to stop using the systems they run the business on today. Here is the sequence, including the ugly parts most proposals leave out.
Step 1: inventory, don't migrate
The first two weeks produce a document, not software. We sit with each department and list every place data lives: which system, who owns it, how the data gets out (API, ODBC, XML export, a person emailing a spreadsheet on the 3rd), how often it changes, and which reports currently depend on it. For a typical mid-market business this list runs eight to fifteen sources: Tally with its XML/ODBC interface, a SQL Server database under a legacy ERP, Google Sheets doing unpaid work as a CRM, a payroll tool, a marketplace seller panel.
Two rules keep this step honest:
- Nothing gets replaced yet. The moment the inventory turns into a migration debate, the project stalls for months while committees form. Operational systems keep running exactly as they are.
- Rank sources by question, not by size. A question like "which SKUs are margin-negative" tells you which three sources matter first. Data nobody has a question for can wait.
The big-migration instinct is strong here, and it is worth naming why we resist it. Migration is what you do after you understand your data. Doing it first means committing a seven-figure budget to move data you have not yet learned to read.
Step 2: one boring Postgres database
Everything flows into a single PostgreSQL instance. Not a fashionable lakehouse, not a streaming platform, just a managed Postgres with three schemas: raw (data exactly as extracted, warts intact), staging (cleaned and typed), and marts (the tables dashboards actually read). The transformations are plain SQL, versioned in Git, run on a schedule. Every choice is deliberately dull, because dull is what survives.
Nightly beats real-time
Almost every client asks for real-time data. Almost none needs it. A finance head deciding credit terms does not act differently on data that is forty seconds old versus twelve hours old; they act on data they trust. Scheduled nightly pulls are far cheaper to build, and far easier to debug because each run is a discrete, replayable event. We start everything nightly and promote a specific table to hourly only when someone can name the decision that requires it. In our experience that happens for one or two tables out of fifty.
The ugly work nobody puts in the proposal
This middle layer is where the real effort goes, and it is why the "just connect a BI tool to Tally" demo falls apart in week two:
- Entity resolution. The same customer exists as three differently spelled ledger names in Tally, an abbreviation in the sales sheet, and an account code in the old ERP. We build a mapping table, have it verified by the people who actually know the accounts, and maintain it as a first-class asset, not a one-time cleanup.
- Unit mismatches. Production logs in kilograms, invoices in cartons, the price list in pieces. Every quantity gets converted to a canonical unit in staging, with the conversion factors written down where anyone can audit them.
- Fiscal-year quirks. April-March fiscal years, voucher dates that differ from effective dates, entries backdated after books close. All calendar logic lives in one shared date table so every report agrees on what "Q1" means.
- Edited history. Legacy systems let users silently change the past. We snapshot on every pull, so when last month's revenue moves, we can say when it moved and by how much, instead of discovering it mid-argument in a review meeting.
Step 3: the first screen with real numbers on it
With even two or three sources cleaned, we stand up an open-source BI tool, Metabase for most teams or Superset where there is more technical depth in-house, pointed at the marts schema. The first dashboard is deliberately small: revenue, gross margin, receivables ageing, stock position. Nothing exotic.
The first review is not a demo; it is an audit. We put the dashboard next to the numbers accounts already signs off on and reconcile them line by line. Every discrepancy gets chased to its source, whether a mapping gap, a unit error or a backdated entry, and fixed in the pipeline, not patched in the chart. This is slow and unglamorous and it is the single highest-value activity in the entire project.
Something shifts in an organization the first time a leadership meeting starts from one screen instead of three conflicting spreadsheets. The argument moves from "whose number is right" to "what do we do about it." That trust is the asset every later step spends.
Step 4: only now, the AI layer
Once the warehouse holds reconciled data with pinned-down metric definitions, the AI layer becomes both easy and genuinely useful:
- Natural-language questions. "Top ten customers by margin decline this quarter" answered in seconds, via an LLM generating SQL against the marts. This works precisely because the schema is small, documented, and unambiguous about what "margin" means.
- Anomaly alerts. A nightly job that flags what a good analyst would: receivables jumping past their usual band, a SKU whose margin quietly dropped four weeks running, a branch that stopped syncing data.
- Simple forecasting. Seasonal baselines for cash flow and demand. We start with boring statistical methods and add model complexity only when the baseline demonstrably fails, which is less often than the market wants you to believe.
We are an AI-first studio, so putting AI at step four may look strange. But we have been called in after the AI-first version: a chat interface pointed at raw exports from three systems that disagree with each other.
An AI layer on top of unreconciled data does not give you wrong answers slowly, the way Excel did. It gives you wrong answers instantly, fluently, and with total confidence.
The model cannot know that two ledger names are the same customer, or that March was restated in April. Garbage retrieval over garbage data is still garbage, delivered faster. Steps one to three are not delays before the AI; they are what makes the AI's answers worth acting on. If you want to gauge where you stand, our one-afternoon AI readiness self-assessment tests exactly this.
Timeline honesty: what six weeks buys, and what it doesn't
The projects we scope usually land in this shape:
- Weeks 1-2: source inventory, access sorted out, first raw extractions from the two or three highest-value systems.
- Weeks 3-4: staging models, entity mapping tables, unit and calendar normalization, reconciliation against known-good totals.
- Weeks 5-6: first dashboards live, a weekly review cadence set, the nightly pipeline monitored and boring.
What six weeks does not buy is full coverage. It buys one domain, usually sales and receivables or inventory and margin, done properly. Each following month adds a domain, and each addition is faster because the plumbing already exists. Anyone promising the whole estate will be trustworthy in six weeks is selling you the demo. Anyone insisting nothing useful can appear before year two is selling you a program office.
When this collides with an ERP decision
Sometimes the warehouse work surfaces a harder truth: the operational systems themselves are the problem. Three item masters for the same product. Duplicate customer records created faster than we can map them. No system anywhere that knows the real stock position. When the pipeline spends most of its effort repairing data the source keeps re-breaking, the honest recommendation changes: fix the data at the source, inside a proper ERP, and let the warehouse read clean data instead of manufacturing it.
We have written candidly about running ERPNext in production for mid-market businesses, and our ERP development practice exists for exactly this fork in the road. The decision rule we apply: if more than roughly a third of the transformation effort compensates for source-system chaos rather than integrating across systems, the ERP conversation comes first. The warehouse still gets built. It just gets built against a source worth reading.
Where to start
- Write the ten-question list. Ten questions leadership cannot answer within an hour today. This one page is the project's real specification.
- Do the inventory yourselves. A spreadsheet of every data source, its owner, and its export path. One afternoon per department, no consultants required.
- Pick one domain. Sales and receivables is the usual winner: high pain, clear numbers to reconcile against, visible to everyone who matters.
- Refuse real-time and refuse big-bang. Nightly pulls, one Postgres database, one open-source BI tool, one reconciled dashboard. Expand from there.
- Hold the AI layer until the numbers have survived an audit-style review meeting. It will land better and cost less for the wait.
The simplest test of whether this play is for you: if month-end takes more than two days of manual work, or two departments report different revenue for the same month, you qualify. The first six weeks will tell you whether the next step is more dashboards, the AI layer, or an ERP conversation, and all three are cheaper than a two-year migration you did not need.