Excel to SMETA software: a 30-day migration playbook
A step-by-step plan Uzbek contractors use to move one active site from spreadsheets into structured SMETA software without losing data or momentum.
Every Uzbek construction firm I talk to has the same migration story: "We meant to move off Excel last year." The spreadsheet becomes the bottleneck at exactly three active sites, and by the time leadership approves software, the team has built fragile routines around it that feel risky to break. This playbook collapses the migration into 30 days so the team stops debating and starts moving.
Week 1 — Pick one site, not the portfolio
The failure mode is trying to convert every active project at once. Pick a single site — ideally one that is 30–60% complete, with the SMETA still recognizable and a cooperative prorab. Freeze the paper SMETA for that site; any change orders from this point live in the new system. Run the old Excel in parallel for the first two weeks. You are not ready to rely on the software yet.
Week 2 — Import SMETA, clean the catalog
Export the SMETA from Excel. Sections, quantities, and unit rates map cleanly into most construction software, but material names never do — the Excel column will be inconsistent ("цемент М400", "cement M400", "М-400 цем."). Normalize these against a single material catalog. An hour spent deduplicating the top 50 materials saves weeks of request mismatches later.
Week 3 — Run material requests through the new system
Freeze the Excel request flow. Every material request from the prorab now goes through the software — even the "just five bags" kind. The warehouse only releases stock against an approved digital request. Expect pushback in the first three days; by day ten the prorab will prefer it because he can see the approval status on his phone instead of chasing the director.
Week 4 — Reconcile and cut over
At the end of week four, run the budget-versus-actual report from both systems. They will not match exactly — the spreadsheet will understate overhead by 5–8% and hide transfer losses. That gap is the real ROI of the migration. Present it to the director, and cut the site fully over to the new system on day 30.
What breaks, and what to ignore
Three things will go wrong. First, a few historical line items will be missing or wrong in the import; fix them lazily as they come up, not in a single cleanup sprint. Second, the warehouse count will disagree with the system in week two — that is the hidden shrinkage from Excel-era transfers. Accept the gap as the new baseline. Third, one senior prorab will resist; put him on the second site, not the first, so the rollout momentum is not held hostage.
Thirty days is enough to prove the model on one project. Month two is replication, not invention.