Direct answer: An Excel-to-ERP cutover in a Rajkot MSME should be planned as a controlled production change, not an IT installation. The safe sequence is: freeze the cutover scope, clean and map masters, run a live pilot beside Excel, execute a timed weekend cutover with open orders and WIP loaded, reconcile to agreed thresholds, and keep Tally for books while the operational system takes over. Production continues because the cutover is rehearsed and the old records stay readable.
Most Rajkot MSME owners do not fear ERP software. They fear the two weeks around go-live: the dispatch that cannot wait, the customer who calls for a status update while the stock sheet is half-migrated, and the accountant who still needs Tally to file GST. That is why the Excel-to-ERP decision in Rajkot is really a production-continuity decision.
The units that cut over cleanly are not the ones with the biggest software budget. They are the ones that decide what "cutover" means before they touch a single master record, and they rehearse the weekend before it counts.
This playbook is written for owners, plant heads and accounts managers in Metoda, Shapar-Veraval and Aji GIDC who run production on Excel, registers and WhatsApp, keep accounts in Tally, and cannot afford to stop the shop floor to become digital.
Why cutover is a production change, not a software switch
A cutover changes the system of record for orders, stock, production status and dispatch. That is an operating change. If the new system cannot answer "where is order 218?" on the Monday morning after go-live, production has already been disrupted, even if every machine is still running.
Rajkot's engineering cluster is not a single homogeneous factory. One dated SIDBI cluster study put the cluster at roughly 2,190 MSME units across foundry, diesel and generator sets, machine tools, automobile parts, pump sets, bearings and forgings, with about 80% micro and 13% small units. That is a 2011 estimate, not a current census, but the composition has not changed in the ways that matter here. A cutover plan that works for a 12-person machine shop will not fit a foundry with heat traceability, outside machining vendors and job-work reporting. The cutover mode must match the production model, not the software brochure.
The Rajkot cutover problem: production does not pause for data
Rajkot's foundry, machining and job-work units share a cutover problem that generic Excel-to-ERP guides underplay: the records are not all in one spreadsheet. They are spread across a master workbook, a production plan copied every morning, a store stock sheet, a receivables file, WhatsApp messages that override the sheet, and job-work challans that live at a vendor's premises.
Any migration start must therefore inventory the spreadsheets the factory actually uses, not the ones management thinks exist. For a Rajkot unit that inventory must also capture heat numbers, WIP at each machining stage, customer-owned material and open job-work challans. If those are treated as history to be imported later, the ERP will go live with an incomplete production picture.
The cutover must load the open operational position, not reconstruct every historical transaction.
Choose your cutover mode before you choose your ERP
The cutover mode is the single biggest decision. It determines how much production risk you carry, how long your team works double, and whether Excel comes back.
| Cutover mode | Best fit in Rajkot | Production risk | What must be true |
|---|---|---|---|
| Weekend big-bang | Single-product-family machine shop or fabrication unit with low open WIP and stable masters | Medium | Masters are clean; open orders and stock are counted; a dry run is complete; Monday users are trained on the exact screens they will use |
| Phased module cutover | Foundry or machining unit with job work, where production cannot be frozen for a full week | Low to medium | One workflow goes live first; other workflows stay in Excel with a named owner and a fixed retirement date |
| Parallel run | High-volume or export unit with traceability obligations | Low, but double work | A fixed end date is agreed; one system is the record; reconciliation happens daily; the window is not extended |
| Hybrid: pilot + weekend | Most Rajkot MSMEs with 20–100 staff | Low | A live pilot on one product family or one customer order type proves the workflow, then the full cutover uses the same validated data |
For most Rajkot MSMEs the hybrid model is the realistic default. It gives the team a live rehearsal without exposing the whole factory to an untested workflow.
If you are still deciding between configuring an off-the-shelf ERP and building a custom operational layer, run the decision tests in custom software vs off-the-shelf ERP before you choose a cutover mode. The cutover plan changes materially depending on which route you take.
The six-week cutover plan
Week 1 — define the cutover boundary. Write down what "migrated" means. For most units it means: every open sales order visible with promised date and balance quantity; every open purchase order visible; opening stock matching a physical count by location; WIP by stage recorded; open job-work challans loaded as documents; and the first invoice generatable from the ERP without retyping. Do not include historical closed transactions unless audit, warranty or batch traceability requires them.
Week 2 — clean and map masters. Deduplicate item codes, standardise units, confirm HSN and tax rates, and assign one owner per data set. Accountability means someone decides whether the data is acceptable, resolves questions and signs off the final version. In a Rajkot unit, stores should own items and opening stock, accounts should own party masters and balances, and production should own WIP and job-work challans.
Week 3 — configure and pilot. Configure the ERP around the pilot workflow. Run one product family or one customer order type through the full loop: order, material issue, production, inspection, dispatch, invoice data. Compare the ERP output with the Excel output. Fix master data, not just screens.
Week 4 — dry-run the cutover. Export the final masters, open orders, opening stock, WIP and job-work challans. Import into a test environment. Reconcile. Measure how long each step takes. The dry run is where you discover that the item master has 14 duplicate "MS Sheet 2mm" variants, not on cutover night.
Week 5 — train on real data and freeze scope. Train each role on the transactions they will actually perform on Monday. Freeze the scope: no new modules, no new reports, no new integrations during cutover. Agree the go/no-go criteria in writing.
Week 6 — cut over and stabilise. Execute the cutover weekend runbook below. Run daily reconciliation for the first week, then weekly for the first month. Keep Excel read-only, not editable.
The cutover weekend runbook
The runbook is not a project plan. It is a timed sequence with named owners and a go/no-go decision.
| Time | Task | Owner | Evidence |
|---|---|---|---|
| Friday 12:00 | Freeze master data: no new item codes, no customer or vendor edits | Stores and accounts | Freeze notice sent; exception log opened |
| Friday 14:00 | Stop edits to operational spreadsheets; capture final versions | Production and stores | Final files archived with timestamp |
| Friday 16:00 | Export final masters, open sales orders, open purchase orders, opening stock, WIP by stage, open job-work challans | Data owner per set | Export register signed |
| Friday 18:00 | Import into the cutover environment; run validation checks | Implementation lead | Import log; error count |
| Friday 21:00 | Reconcile item count, stock value, open order quantity, WIP quantity, party balances | Accounts and stores | Reconciliation sheet with variances |
| Saturday 08:00 | Production entry begins in the ERP for new transactions | Plant head | First job card created in the ERP |
| Saturday 12:00 | First dispatch or invoice from the ERP; compare with the Tally entry | Dispatch and accounts | Invoice and Tally voucher matched |
| Saturday 18:00 | Go/no-go review: variance within thresholds, critical workflow passes, users complete their tasks | Owner and plant head | Signed go/no-go sheet |
| Sunday 10:00 | Fix remaining exceptions; load any missed open documents | Data owners | Exception log closed |
| Monday 08:00 | Shop floor uses the ERP; Excel becomes read-only reference | All users | Daily stand-up notes |
If the go/no-go review fails, do not force the cutover. Extend the dry run or run the pilot workflow for another week. A delayed cutover is cheaper than a wrong Monday.
Data freeze rules that protect production
A freeze is not a suggestion. It is the boundary that makes reconciliation possible.
- No new item codes after Wednesday. New items during cutover create duplicates and break opening stock.
- No master edits after Friday noon. Price changes, credit limits and tax rate changes must wait.
- Capture open orders with balance quantity and promised date. Do not import closed orders just to make the system look full.
- Count stock at a precise cut-off and bridge movements. If counting happens while the factory operates, record receipts and issues between the count time and the import time. Double-counting is how a 20-piece phantom variance appears.
- Load job-work challans as open documents. Pending quantity, ageing and return expectations matter more than historical challans.
- Attach heat numbers to WIP lots before cutover. Do not plan to reconstruct heat traceability after go-live.
Reconciliation thresholds: what "good enough" means
"Zero variance" is rarely achievable in a live factory. Agree thresholds before cutover and record them in the sign-off sheet.
| Data set | Recommended threshold | Why |
|---|---|---|
| Active item master count | 100% of approved items loaded; 0 duplicates | Duplicates corrupt every bill of materials and stock report |
| Opening stock quantity by location | 100% physical count loaded; movement bridge documented | Quantity errors surface as production shortages within days |
| Opening stock value | Within 1% or an agreed rupee amount | Valuation differences are normal; unexplained differences are not |
| Open sales order quantity | 100% of open lines matched | Missing open orders mean missed dispatches |
| Open purchase order quantity | 100% matched | Missing open POs mean duplicate purchasing |
| WIP quantity by stage | 100% counted at each stage the unit tracks | Total WIP alone hides stage-level shortages |
| Open job-work challan quantity | 100% loaded with pending quantity and vendor | Unloaded challans become "lost" material |
| Party balances | Agreed with Tally and signed off by accounts | The operational view and the books must tell the same story |
These are recommendations to adapt, not an industry standard. The point is to write the thresholds down and decide against them at the Saturday review. For a deeper look at why different systems show different numbers, see when dashboards show different numbers.
Tally coexistence without double entry
One Rajkot reality is non-negotiable: the accounts team and the CA are not giving up Tally, and GST filing depends on it. The workable model is operational ERP plus Tally books, with one system of record per data type.
- The ERP owns sales orders, production status, stock, WIP and job-work challans.
- Tally owns the financial ledger, GST returns and statutory accounts.
- Invoice data moves from ERP to Tally through an agreed integration or a controlled export; it is not typed twice.
- The accounts team continues to work in Tally; the operations team moves off Excel and WhatsApp.
- The cutover plan must include the Tally boundary: who posts the first ERP-generated invoice, who reconciles it, and what happens if the integration fails.
If the integration is not ready, do not delay the operational cutover for it. Run the first week with a controlled daily export and reconcile manually. A temporary manual bridge is safer than delaying production visibility.
WIP, job work and heat numbers
These are the three data sets most likely to be under-scoped in a Rajkot cutover.
WIP by stage. A foundry or machining unit does not have one WIP number. It has WIP at moulding, pouring, fettling, machining, inspection and packing. Load WIP at the stage level the plant actually manages. If the ERP only supports total WIP, agree an interim stage-tracking method rather than pretending the detail exists.
Open job-work challans. Material sent to a machining or plating vendor is not "stock in the warehouse." It is an open document with a vendor, a pending quantity, an expected return date and a job-work reporting obligation under GST rules — commonly filed on the ITC-04 form. Confirm the current filing requirement with your tax adviser. Load these as open job-work documents, not as historical transactions.
Heat numbers. A heat number is an attribute of a lot, not a separate stock item. Attach heat numbers to the WIP and finished-goods lots that exist at cutover. Do not attempt to reconstruct heat genealogy for closed orders unless a customer or export requirement demands it. The cutover scope should state explicitly which open lots carry heat traceability into the ERP.
After cutover: stop the shadow spreadsheet from returning
The biggest post-go-live risk is not a software bug. It is the unofficial stock sheet that reappears because someone does not yet trust the ERP. Users keep a private sheet when the ERP cannot answer a question quickly enough. Contain it with four rules:
- Name one process owner for the first 30 days. This person owns the exception log and the daily reconciliation.
- Publish a one-page daily status report from the ERP. If the ERP is the only place to see order status and stock, the shadow sheet loses its reason to exist.
- Run a weekly reconciliation for four weeks. Compare ERP stock and open orders against the physical position, not against the old Excel file.
- Retire Excel formally. After the agreed stabilisation period, move Excel files to read-only archive and remove edit permissions. Do not leave an editable copy "just in case."
Common mistakes
- Choosing the ERP before choosing the cutover mode. The software decision is separate from the production-continuity decision.
- Importing every historical row. History feels safe but increases risk; load the open position and archive the rest.
- Treating Tally as the enemy. Tally stays for books; the ERP takes operations.
- Skipping the dry run. The dry run is where duplicate item codes and missing open orders are found.
- Letting the parallel run run forever. An open-ended parallel run creates permanent double work and slowly pulls the team back to Excel.
- Promising "zero downtime" without defining it. Define what must keep running: dispatch, customer status, job-work returns and GST invoicing.
- Not counting WIP by stage. Total WIP hides the shortage that stops a machining line on Tuesday.
When to involve a specialist
Bring in an external specialist when the unit has multi-level bills of materials, heat traceability, export documentation, ITC-04 job work, or an existing Tally integration that must survive cutover. Bring one in earlier if the internal team cannot name a single process owner for the cutover, or if the vendor's implementation plan does not include a dry run and written reconciliation thresholds. Use the manufacturing software vetting checklist to check whether the partner has actually walked a plant process, not just demonstrated a dashboard.
First-hand experience: JUHENZA has not published a Rajkot-specific cutover case study. The process above is built from documented migration practice, Rajkot cluster context and the operating realities of foundry, machining and job-work units. Treat it as a planning framework, not a substitute for a real cutover log.
Frequently Asked Questions
Can a Rajkot MSME cut over from Excel to ERP without stopping production?
Yes, if the cutover is scoped to the open operational position and rehearsed before the live weekend. Production continues because machines, dispatches and job-work returns are not paused; only the record-keeping system changes. The risk is not the machine stopping — it is the new system not being able to answer a production question on Monday morning.
How long does an Excel-to-ERP cutover take for a Rajkot MSME?
For a 20–100 person unit with a defined pilot workflow, a realistic planning window is four to six weeks from scope freeze to stabilisation. The first week defines the cutover boundary, weeks two to four clean and pilot, week five trains and freezes scope, and week six executes and stabilises. A single machine shop with clean masters can move faster; a foundry with heat traceability and open job work should not compress the dry run.
What data must be migrated at cutover?
At minimum: active item masters, customers and vendors with GST details, units and conversions, opening stock by location, open sales orders, open purchase orders, WIP by stage, open job-work challans, and party balances agreed with Tally. Historical closed transactions should be archived unless audit, warranty or batch traceability requires them.
Should we run parallel or go for a weekend big-bang?
Use parallel only with a fixed end date and one agreed system of record. For most Rajkot MSMEs a hybrid model is safer: pilot one workflow live, then use a weekend cutover for the full open position. A pure big-bang is reasonable only when masters are clean, open WIP is low, and the team has completed a dry run.
How do we handle heat numbers and job-work challans during cutover?
Load heat numbers as attributes on open WIP and finished-goods lots, not as separate stock items. Load open job-work challans as documents with vendor, pending quantity and expected return date. Do not attempt to reconstruct heat genealogy for closed orders unless a customer or export requirement demands it.
Do we have to stop using Tally?
No. Keep Tally for the financial ledger, GST returns and statutory accounts, and let the ERP own operations. The cutover plan should define the invoice boundary between the two systems so the accounts team does not type the same invoice twice.
What is the biggest cutover risk?
The biggest risk is an incomplete open position: missing open orders, unloaded WIP, or job-work challans that exist only in a WhatsApp message. The second is the shadow spreadsheet returning after go-live. Both are managed by scope discipline, reconciliation thresholds and a named process owner for the first 30 days.
When should we involve an external specialist?
Involve a specialist when the unit has multi-level bills of materials, heat traceability, export documentation, ITC-04 job work or a Tally integration that must survive cutover. Also involve one if no internal process owner can be named, or if the partner's plan lacks a dry run and written reconciliation thresholds.
Next step
The Rajkot MSMEs that cut over cleanly do not treat Excel-to-ERP as a software purchase. They treat it as a controlled production change: one cutover mode, one open position, one dry run, one weekend runbook, one set of reconciliation thresholds and one owner for the first 30 days.
If you are planning a cutover in Metoda, Shapar-Veraval or Aji GIDC, start by mapping the workflow you will move first and the data sets that workflow depends on. JUHENZA builds enterprise software and ERP integrations around real operating workflows; you can review selected work and project scopes or describe your cutover problem for a practical starting point.
References
- SIDBI — Credit Gap Mapping in 10 MSME Clusters in India, Rajkot cluster summary. Used for the engineering cluster composition. This is a 2011 estimate, not a current census.
- NIST — ERP implementation helps farm equipment manufacturer support growth. Used for the principle of process mapping, cross-functional participation and clean data before implementation.
Cutover timings, thresholds and the runbook are planning aids drawn from documented migration practice, not guarantees. Tax and statutory references are informational and not professional advice.