# Migrating from MSSQL, Access or another database

SQL Server, Access, a phone app - how to get your data out of it, or hand it to us and we do it.

Some old systems don't have an **Export** button - they have a database. This page covers the three we're handed most often, and the shortest way out of each. If any of it looks like work, skip to **Or just send it to us** at the bottom: that lane is free, and we tell you the day it will land.

## SQLite (.sqlite, .db) - upload it as it is

Phone-era job apps and small dispatch tools keep everything in a single `.sqlite` or `.db` file. **You don't need to convert it.** Open **Import data**, drop the file in, and it's read exactly like a database dump: you get the list of tables with row counts, the **Bring everything across** button, and the same mapping, preview and undo.

- The file is usually next to the app's own backup or export option - anything ending `.sqlite`, `.sqlite3`, `.db` or `.db3`
- We only read it. Your file is never written to, and the copy we open is deleted the moment the import bytes are built
- **Photos and signatures kept inside the database come across blank** - they're pictures, not columns, and there's nothing to map them to. Everything else on the row still imports
- **Dates stored as numbers are converted for you.** A lot of phone apps keep dates as a count of seconds - `1704067200` instead of `01/01/2024`. Where a column's name and its values both say *timestamp*, we read it as a real date on the way in, in **your workspace's timezone** (Settings → Tax and region → Timezone), so a 10am job lands on the day you worked it. The table list names the columns before you import anything
- A column we don't convert - a reference number that happens to look like a timestamp, say - comes across exactly as it was stored, and you can still wrap it yourself in **Combine tables with SQL**. A query there runs exactly as written: `datetime(job_date, 'unixepoch')` reads as UTC, so add an offset (`'+10 hours'`) if your old app wrote local times, and check **Preview query** before importing

> **Close the old app before you copy its database - or use the app's own backup/export.** Most phone apps keep the records written most recently in a second file beside the database (you'll see the same name ending in `-wal`). Copy the database on its own while the app is running and your newest jobs simply aren't in it - the import will look perfectly successful and be short. If we spot that, we say so above the table list; either way, check the row counts against what your old app shows before you commit.

## Microsoft SQL Server - export to CSV from SSMS

A `.bak` is a backup, not an export: only SQL Server itself can open one. If you have SQL Server Management Studio, twenty minutes gets you clean CSVs.

1. Connect to the server in **SSMS** and find the database in Object Explorer
2. Right-click the database → **Tasks → Export Data…**
3. Data source: **Microsoft OLE DB Driver for SQL Server** (on older installs, **SQL Server Native Client**), pointed at that database. Destination: **Flat File Destination**
4. Choose a file name ending `.csv`, tick **Column names in the first data row**, and leave the format as delimited with a comma
5. Choose **Copy data from one or more tables or views**, tick the tables you want (jobs, customers, vehicles, invoices, drivers, trucks), and run it
6. Repeat per table - SSMS writes one file at a time - then upload the CSVs here, clients before jobs

> No SSMS and no server any more? Send the `.bak` through a support ticket instead. Restoring a backup is our job, not yours.

## Microsoft Access - the export wizard

1. Open the `.mdb` or `.accdb` in Access
2. In the left pane, click the table you want (start with customers/clients)
3. **External Data → Export → Text File**, name it `.csv`
4. Choose **Delimited**, comma, and tick **Include Field Names on First Row**, then Finish
5. Repeat per table and upload the CSVs here

> Access files often hold a lot of tables with cryptic names. You don't have to work out which is which - export them all and we'll tell you what's in each, or send us the file.

## Anything else

MySQL and MariaDB: `mysqldump -u user -p dbname > backup.sql` and upload the `.sql`. PostgreSQL: `pg_dump --format=plain dbname > backup.sql`. Both are read directly here, table by table.

```
mysqldump -u root -p my_old_app > backup.sql
pg_dump --format=plain my_old_app > backup.sql
```

Still on paper, or on a spreadsheet that isn't really a spreadsheet? **Import data → Start from a blank template** gives you an Excel or CSV file with the right column headings already in it and one example row to type over. Fill it in at your own pace and upload it when you're ready.

## Or just send it to us

**Support → New ticket → Data migration**, attach what you have, and we bring it across for you - free, and we tell you the day it will land. `.bak`, `.mdb`, `.accdb`, `.sql`, spreadsheets, ZIPs of the lot: all accepted.

- Up to **five attachments a message**, each within the upload limit - a real SQL Server backup is usually bigger, so **zip it first** (they compress hard), or split it and send it across a few replies
- Too big even zipped? Say so on the ticket and we'll arrange another way to get it across - don't spend an afternoon on it
- A `.sqlite` or `.db` file doesn't need a ticket at all: upload it on the Import data screen. If yours is over the upload limit, zip it and attach the zip here instead
- Tell us what the system was called and roughly what's in it. You don't need to know the table names

> We reply on the ticket when it's done, you check a handful of real records, and anything that looks off we fix. Every import we run can be undone, exactly like one you'd run yourself: anything used since is named and kept.