Technology
Stone Fabrication Software Migration Checklist
Before switching stone fabrication software, test whether the records your team needs are complete, accurate, and usable in the new system. Reconcile customers, open jobs, drawings, inventory, schedules, and any financial balances included in the agreed scope. Use representative jobs and written acceptance checks instead of treating an import-success message as proof that the shop can work.
The import finishes without an error. On Monday morning, an estimator cannot find the latest drawing, the warehouse sees duplicate slab IDs, and the installer has no record of a changed appointment. The data moved, but the team cannot yet rely on it.
A migration acceptance checklist tests the work the shop needs to perform after switching. Agree on the scope first, then compare actual records and complete representative tasks. This is a focused acceptance process; our software switching guide covers the wider rollout and training plan.
Agree on What Will Move
List the record types, date range, attachments, relationships, and open transactions included in the migration. Name what stays in the old system or a read-only archive. Ask the vendor to confirm the exact import scope in writing.
Do not assume that an available export establishes an available import. A file may contain customers and totals without the drawings, item relationships, historical changes, or attachments that give those numbers meaning. Keep source copies and avoid modifying the only available export.
Choose Representative Jobs
Select jobs that exercise different parts of the workflow. Include a newly quoted kitchen, an approved job waiting for material, work in production, an installation appointment, and a completed job with an open balance if those records are in scope.
Add a changed order and a remnant job when they matter to your shop. For each test, record the source reference, expected result, actual result, reviewer, and unresolved difference. These are proposed test cases, not a claim that any vendor imports every record automatically.
Run the Record Checks
Customers: identities, contacts, addresses, and duplicate handling are correct.
Jobs: job numbers, customer relationships, scope, and status agree.
Drawings and files: the right revision and required attachments can be found and opened.
Inventory: piece IDs, dimensions, locations, quantities, and allocations match the agreed snapshot.
Schedule: dates, times, assignments, and local-time display are correct.
Financial records: included order totals, invoices, credits, and payments reconcile under the agreed migration method.
Access: each role can find and use the information required for its work.
Archive: the team knows where excluded history remains available.
Compare totals, but also inspect the relationships behind them. Ten open jobs assigned to the wrong customer is not a successful migration just because the record count is ten.
Reconcile a Small Example Before the Full Cutover
Suppose three in-scope open invoices are $2,000, $3,500, and $1,000. Their total is $6,500. If the target shows $6,000, the $500 difference needs an explanation before acceptance.
If the target also shows $6,500, inspect the individual records. One duplicated $1,000 invoice and one missing $1,000 invoice can produce an agreeing total. Check customer and job links, credits, and applied payments as well. These figures are hypothetical and do not describe a Stonify import format.
For financial cutover, have the person responsible for the books approve the method and balances. Operational tests should confirm that the team understands which system owns new transactions after the switch.
Test a Working Day With Each Role
Ask an estimator to locate a customer, review the current drawing, and continue an open quote. Ask the warehouse team to find an allocated slab. Ask scheduling and field staff to retrieve an appointment and its current job instructions.
Record where someone needs a workaround or cannot complete the task. Training issues and missing data need different fixes. Re-run the failed check after the correction and record the result; a verbal promise to fix it later is not acceptance.
Define the Cutover Decision
Keep a list of unresolved issues with owners and consequences. Decide which issues block cutover and which can be handled through an agreed temporary process. Identify who can approve the switch and how the team will respond if a critical check fails.
Account for transactions created between the test snapshot and cutover. A correct test import can become stale while the shop continues working. Confirm the final update method and reconcile it before people begin entering new work in the target system.
Evaluate Stonify With Your Own Jobs
Stonify connects quoting, inventory, scheduling, and finance in a fabrication workflow. That makes it a strong choice to evaluate when the reason for switching is repeated entry and disconnected job information. Use the fabrication software selection guide to build your requirements.
Confirm the current migration scope for your source system directly with Stonify. This article does not promise a particular importer, automatic history transfer, or completion time. The acceptance tests help you verify the agreed result.
Test Your Next Shop System Against Real Work
Book a Stonify demo and bring representative jobs plus your migration questions. Review how the connected workflow fits your shop and establish what must be verified before you switch.
Related Articles
How to implement or switch countertop shop software without losing data
A step-by-step plan for moving a stone shop onto new software: timing, data migration, testing, parallel running, cutover and training by role.
How to choose countertop fabrication software: requirements, pricing models and questions to ask
A buyer's guide for stone shops: define requirements, test vendors with your own jobs, compare pricing models and total cost, and avoid common traps.
Stone shop management software and ERP: what it is, whether you need it and how to judge the payback
What a countertop shop management system or ERP does, all-in-one vs separate tools, when a true ERP makes sense, and how to estimate software ROI from your own numbers.