The second migration was the easy one

A sister company started its own migration right away

The first migration is told in How a flooring wholesaler left 15 years of Zoho patches in one month. The wholesaler ended up off Zoho, without the outside consultant it had needed for every change, and with a web portal where its customers check inventory and submit purchase orders.

The sister company did not wait to see how that settled. It started its own migration right away. It is a separate business, so its records went into its own database. Nothing was shared with the first company's records.

What the second company's data looked like

Its records came out of Zoho as spreadsheet exports: an inventory list, a barcode list and a vendor list. Each piece in the inventory list, such as a rug or a sample, has its own barcode. The inventory list also held pieces that were long gone: sold, returned, out with customers or tied to old purchase orders.

That set three requirements for the import:

Every row is accounted for. Each row in the files ends up in exactly one place in the new database, and no row is dropped without a record of why.
Old barcodes still work. A label printed years ago still finds its record.
History never counts as stock. A rug sold years ago must not appear as something a salesperson can quote today. Old purchase orders are kept as history and are never sent to vendors again.

The work used the files the company had already sent. Its staff were not asked to find or export more data.

Illustration titled Every row has one place. A plain file labeled Inventory list feeds two bins. The green bin is labeled On hand: can be sold. The grey bin is labeled Kept as history: not for sale, with tags reading Sold, Returned, With customers and Needs review. Each bin has a tag reading Barcode kept. A bar at the bottom reads: Every row kept. Only on-hand stock can be sold. — Figure 1. Each row went to one place: stock that can be sold, or history that is kept but cannot be sold. Simplified for illustration.

What carried over and what was new

Some of the second migration was new work and some was not.

Part of the work	Reused or new	Detail
Import method and checks	Reused	The importer followed the pattern built for the first migration: check the input files, rehearse on a copy, back up, apply in one transaction, verify and run again
Database tables	Existing	The records went into existing tables. No tables were added and the schema was not changed for this import
Source mappings	New	The inventory, barcode and vendor spreadsheets were mapped to those tables
History rules	New	Which pieces are on hand and which are kept only as history
Database	New	A separate database for the sister company

The second migration was easy because of the first. What we learned moving the first company became the tools used for the second: the import method and the checks before and after it. The sister company's mappings, history rules and database were new. The way they were built and checked was not.

Illustration titled What carried over, what was new. On the left, a blue card labeled Reused from the first migration lists Import method and Checks before and after. On the right, a sky blue card labeled New for the second company lists Spreadsheet mappings, History rules and Its own database. An arrow joins the cards. A bar at the bottom reads: The second company started from a method that already worked. — Figure 2. The import method came from the first migration. The mappings, history rules and database were new.

How the import was run

The import was run the same careful way as the first one, in six steps:

Check the input. Before touching any database, the importer checked each file's fingerprint and expected row count. It would stop if a file differed from the version the plan was built on.
Rehearse on a copy. A fresh copy of the production database was made from a backup. The full import ran there first, followed by the same checks planned for the real run.
Back up and verify. Before the real run, a backup of the live database was made, its checksum was verified and a copy was stored off the server, so the database could be restored if anything went wrong.
Apply in one transaction. The import wrote everything in a single transaction, and only to the database it was told to use. Either all of it is saved or none of it is.
Check independently. A separate check recounted the products, inventory pieces and historical purchase orders. It also confirmed that no piece kept as history could be held for a customer's quote.
Run it again. The import was run a second time straight away. It reported zero inserts, zero updates and zero deletes.

The last step tells you the most. A second run that changes nothing shows the import wrote everything it was meant to and nothing more. When the next set of files arrives, or a mapping needs a fix, the import can be run again from a known state. Why your data import should be rerunnable explains the method in more detail.

Why a second migration can cost less than the first

A second company, a new location or an acquired business brings new files. If the first migration left behind an automated import with its checks, the second one does not start from nothing. The new work is the part that is actually different: mapping the new files and deciding how that company's history should be treated.

The same pattern holds at much larger scale. Intelligence Factory's published case study on integrating dozens of EHR systems describes data from nearly three dozen EHR and EMR systems mapped to one internal ontology, with the mappings for each source kept separate from the rules that use the data for eligibility, billing and reporting. Because each source has its own mapping, adding a source means adding a mapping, not rewriting the rules. Put business rules in your data model, not in code or a chatbot covers where those rules should live.

Questions to ask before you add a second company

If you expect to bring another company, location or acquisition onto your system, ask these about your first migration:

Can the import be run again from scratch today, without anyone editing records by hand afterward?
Does it check its input files before it writes anything?
Is it rehearsed on a copy of production, with a verified backup taken before the real run?
Does it write everything in one transaction?
What does a second run report? It should be zero changes.
How are sold items, returns and closed orders kept so they never count as current stock or open orders?
Will the new company's records be kept separate, and who decides which records are shared?

If the answers are no, expect the second migration to repeat much of the first one's work.

Adding a company, location or acquisition

If you are planning to bring a second business, a new location or an acquired company onto your system, tell us what its data looks like and where it lives. We will tell you what can be reused from the work you already have and what has to be built. Tell us about your current system, or read how full service works.