Excel to SQL Database Migration with Record Checks
Moving Excel data into SQL is not just copying rows to a different storage location. Customers, orders and products need reliable identities and relationships. I plan the migration around those connections, keeping missing or ambiguous records visible rather than inventing information to make the import appear complete.
SQL is a language for querying and managing records in a relational database. This service moves workbook records into the database behind your application. Your team’s daily work does not need to involve writing database commands. Search, entry and permission screens are designed separately. Data migration and a usable operational application are related but distinct parts of the scope.
Example: One of three orders needs review
The illustration uses fictional sample records. The customer table contains two customers, C-01 and C-02. The order table contains three orders. S-01 belongs to C-01, and S-02 belongs to C-02. The remaining order refers to C-99, which is absent from the customer table.
The correct outcome is two orders imported and one held for review. Attaching the third order to the first customer, or silently dropping it, would conceal the problem. Its source file and row stay available. An authorised reviewer decides whether the missing customer should be added or the incorrect reference corrected.
Understand the workbook before moving it
I examine differently written customer names, reused numbers and cells containing several products. A customer name can change, so it should not be the only relationship key. Dates, amounts and codes with leading zeros require explicit conversion rules. When duplicate records are merged, the selection and reason need to remain reviewable.
The trial import uses copied source data. We compare relationships and representative totals as well as row counts. A cutover point determines how the final workbook edits are handled. If the spreadsheet and application both remain editable, their respective authority must be agreed rather than left ambiguous.
When a database is useful
Structured Excel tables, stable record identifiers, validation and Power Query may already meet the need. Supported Microsoft 365 setups also offer co-authoring; having several users does not alone justify SQL migration. I first assess whether a clearer workbook structure is sufficient. A database becomes useful as related record types, permissions and shared transactions grow. Migration alone does not guarantee speed, security or correctness. Access controls, backups and application rules still need implementation and testing.
Making the scope testable
I start with a de-identified example of your current file or screen and the roles of the people using it. The written scope defines where each field comes from, who can change it and where the result goes. I test a missing relationship such as C-99, a code with leading zeros and an edit after the cutover point. Imported, held and deliberately excluded rows must reconcile to the source.
The scope also covers exports, the backup approach and who handles failures. We review the first version against one real workflow before planning further connections.
Frequently Asked Questions
Must every historical file move at once?
No. A phased migration can preserve relationships while limiting the initial scope. Each phase identifies which source is editable and which is retained for reference, preventing competing versions of the same record.
Will the spreadsheet formulas continue unchanged?
A workbook formula is not automatically a database calculation. I identify which calculations move into the application and whether historical calculated results should be preserved separately.
Can we return to the old setup?
The source backup and cutover plan are prepared for that possibility. Once new transactions exist in the application, returning requires reconciliation. Simply reopening an older workbook would not account for those changes.
Discuss your workflow
For a related workflow, see Supplier XML Product and Stock Integration. Explore custom web applications for your team or contact me with an example of the process you want to improve.
How do I work?
Work-hour packages
Tell me about your business and what you need on WhatsApp or by phone; we agree on a work block of somewhere between 5 and 40 hours and I start doing what is needed. What you get is not a calendar window — it is net working hours spent directly on your business. I can use 40 hours working three days straight, or deliberately spread it out and finish it over a year — whatever the work calls for. I do not spend my time estimating how long something will take, I spend it doing the work; every hour I spend leaves a lasting result in your business. We keep going for as long as you find it useful.
Why not monthly?
Is 40 hours a week?
On a fixed monthly fee both sides are watching the wrong thing: you watch a fixed cost, the other side watches how many more contracts like this they can line up. Working by the hour puts us both in front of the same thing — the real value of the work that got done. I know not having an upfront answer to "how much will this cost in total?" is the natural cost of this model. But instead of paying a fixed fee for months to a setup that is not producing results, you only pay for the qualified time spent on your work — and you see exactly where that time went, start to finish. That is why my clients keep coming back.