ITFlow Migration

Import your data from ITFlow into Ascent so you can switch without re-keying your clients. The migration is read-only and one-directional — nothing is ever written back to your ITFlow database.

Ascent imports your core CRM records (clients, contacts, locations), your assets & infrastructure (vendors, assets, software, licenses, domains, certificates, networks), your PSA records (technicians, tickets, ticket replies, time entries), your billing records (products/services, recurring invoices, quotes, invoices, their line items, and payments) and your documentation & knowledge base (documents — which in ITFlow double as the knowledge base). Your ITFlow password vault can also be imported when you connect to the live database and supply your ITFlow master key (see below), and your file attachments can be imported by uploading an archive of ITFlow's uploads/ folder alongside the run (see the note below).

ITFlow is a self-hosted PHP/MySQL app with no full-export API, so Ascent imports directly from your ITFlow database — either from an uploaded database backup (.sql / .sql.gz, the easiest option) or over a read-only MySQL connection you provide. See Choosing a source for which to use.

Who can run a migration

Running a migration is available to the organization Owner and Admins by default. Because it is controlled by a dedicated migrations permission, you can also create a custom role that grants migration access to specific people and withhold it from other admins. It handles raw database credentials and bulk-creates records, so grant access deliberately.

Choosing a source

There are two ways to bring your ITFlow data into Ascent. Pick whichever is easier for your setup — both import the same data with the same guarantees.

1. Upload an ITFlow backup (recommended). Export a database backup from ITFlow and upload the file. This works even when your ITFlow database can't be reached directly (it's behind a firewall/NAT, or you'd rather not open the database port). It's the default option in the migration screen.
2. Connect to the live database. Provide a read-only MySQL connection to your ITFlow database. Best when Ascent can reach the database directly.

Password vault — live database + master key only

ITFlow encrypts every vault entry with a per-site master key that is not stored in the database — so it's absent from a backup file. To import your vault you must use the live database source and supply your exported ITFlow master key (see Option 2 below). On a backup upload — or a live connection where you leave the master key blank — vault entries are skipped and everything else imports normally.

File attachments — upload your uploads/ folder

ITFlow keeps uploaded files on the server's filesystem (under uploads/), with only their metadata in the database — so the database (whether read live or from a backup) doesn't contain the file contents. To import your attachments, add an attachments archive to the run: a .zip or .tar.gz of your ITFlow uploads/ folder. Ascent matches each archived file to its record and re-hosts it. Files attached to an asset, document or quote are imported; files that were only attached to a contact, or that live at the client level with no other link, have nowhere to attach in Ascent and are skipped (and noted in the run log). Document text (and the knowledge base) always imports fully, archive or not. See Importing file attachments below.

Option 1 — Upload an ITFlow backup

In ITFlow, go to Settings → Backup and download a database backup (documented at docs.itflow.org/backups). You can upload it as a plain .sql file or a gzipped .sql.gz file.

1. Go to Admin → ITFlow Migration.
2. Leave the source set to Upload backup (the default).
3. Choose your .sql / .sql.gz file and click Upload & validate backup.
4. Ascent checks that the file is a valid ITFlow backup, shows the detected ITFlow version and how many tables it found, and stores the file encrypted at rest. The stored file is removed automatically once the import finishes.
5. Press Start. The import runs in the background and you can watch per-entity progress (pulled / loaded / skipped / failed).

tip

Large ITFlow databases are processed in memory, so very large backups may be rejected (there's a size limit your administrator can configure). If your backup is too large, use the live-database source instead.

Option 2 — Connect to the live database

You need a MySQL connection to your ITFlow database. We strongly recommend creating a read-only database user for this. You'll provide:

• Host — the hostname or IP of your ITFlow MySQL server (reachable from Ascent).
• Port — usually 3306.
• Database — your ITFlow database name (often itflow).
• User / Password — ideally a read-only MySQL user.
• ITFlow master key (optional) — supply this to import your password vault. Leave it blank to skip the vault (everything else still imports).
• Use TLS — enable if your database requires an encrypted connection.

tip

Only SELECT queries are ever issued against your ITFlow database, and a read-only user enforces that at the database level.

Importing the password vault. ITFlow encrypts each vault entry under a per-site master encryption key that never leaves your ITFlow server, so Ascent can only decrypt the vault if you provide that key. In ITFlow, go to Admin → Backup, confirm your password, and copy the master encryption key it displays. Paste it into the ITFlow master key field. Ascent stores it encrypted at rest, uses it only to decrypt the vault during the run, and never displays it or writes it to logs. Each imported credential's password and one-time-password secret are re-encrypted under Ascent's own per-organization key. An entry that can't be decrypted (for example, if the key is wrong) is skipped and noted in the run log rather than failing the whole import.

1. Go to Admin → ITFlow Migration and choose Connect live database.
2. Enter your Host, Port, Database, User and Password (and toggle Use TLS if needed). Optionally paste your ITFlow master key to import the password vault.
3. Click Test connection. Ascent connects and runs a quick probe. A clear error is shown if the credentials are rejected.
4. Click Create migration. Your credentials (and the master key, if provided) are validated and stored encrypted at rest; they are never shown again or written to logs.
5. Press Start. The import runs in the background and you can watch per-entity progress (pulled / loaded / skipped / failed).

Importing file attachments

Your ITFlow files (the binaries under uploads/) aren't in the database, so to bring them across you upload an attachments archive alongside the run. This works with either source (backup upload or live connection).

1. On your ITFlow server, make an archive of the uploads/ folder — a .zip or .tar.gz (also .tgz / .tar). Keep the folder structure intact (uploads/clients/…).
2. In Admin → ITFlow Migration, before you create the run, choose your archive in the Attachments archive (optional) field on either form.
3. Create the run as usual. Ascent uploads the archive, stores it encrypted at rest, and attaches it to the run.
4. Press Start. As the import runs, each file is matched to its record by its stored filename and re-hosted into Ascent.

What gets attached:

• Files attached to an asset, document, or quote are imported and linked to that record.
• Files attached only to a contact, or that sit at the client level with no other link, have no matching place in Ascent and are skipped (noted in the run log) — they're never turned into empty, broken attachments.
• A file referenced in ITFlow but missing from your archive is logged as an error and the rest of the run continues. Very large files (over 50 MB) are skipped and logged.
• Files you deleted in ITFlow (archived) are skipped, so the migration doesn't bring back attachments you removed.

Leaving the archive blank simply skips attachments — everything else still imports. The archive is removed automatically once the import finishes, and its size is bounded by a limit your administrator can configure.

How it works

• Throttling — every query goes through a conservative rate limiter, so a migration won't overload your live ITFlow database.
• Idempotent — each ITFlow record is matched to its Ascent record by source id. Re-running a migration updates existing records instead of creating duplicates.
• Resumable — progress is tracked per entity and per record id. If a run is interrupted, starting it again continues from where it left off.
• Reported — each run produces per-entity counts plus a log of skips and any records that failed (with the raw data retained for review).

Watching a run

Once you press Start, the migration page keeps itself up to date — you do not need to refresh:

• Live status — the run is polled automatically while it is in progress and updates on its own; a spinning live indicator shows it is being tracked. Right after you press Start the run briefly shows Starting while the background worker picks it up, then moves to Running on its own. Polling stops once the run finishes, fails or is cancelled.
• Reference id — each run shows a short reference id you can copy. If you need support to look into a run, share this id — it matches the run in the background worker's logs.
• Progress — each section of data (Clients, Tickets, Invoices, …) shows a progress bar and live counts: pulled (read from ITFlow), loaded (imported), skipped (intentionally not imported, e.g. an orphan) and failed. You also see when the run started, when it finished, and how long it has been running.
• Details — click View details on a run to see a breakdown of every record that was skipped, had an unmapped value, or errored, with the reason for each. If a run fails, the error is shown right away. This is the fastest way to understand exactly what happened and why. (Secrets are never shown — connection passwords and the uploaded backup are never displayed.)

What is mapped

ITFlow	Ascent	Notes
Clients	Clients	Client name carries over; leads import as Lead-type clients; archived clients import as Inactive. The ITFlow client id is kept as the client's reference number, and currency / net terms carry over when set.
Contacts	Contacts	Linked to their imported client. The primary / billing / technical flag sets the contact type. A contact whose client was not imported is skipped and logged.
Locations	Locations	Linked to their imported client, with the primary-location flag preserved. A location whose client was not imported is skipped and logged.
Vendors	Vendors	Imported at the organization level (name, website, email, phone, notes).
Assets	Assets	Linked to their imported client (assets with no imported client are skipped and logged). The ITFlow asset type maps to Ascent's asset type — an unrecognized type imports as Other and is flagged in the run report. Make, model, serial, OS, purchase/warranty dates and physical location carry over; the asset's location is linked when it was imported.
Software	Software	Linked to its client when present (otherwise imported at the org level). License type, seats, version and dates carry over; the vendor is matched to your imported vendor by name.
Licenses	Software + license key	Each standalone ITFlow license imports as a software entry, and its license key (when present) is stored as an encrypted license key with the seat counts preserved.
Domains	Domains	Linked to their imported client (orphans skipped). Expiry date and nameservers carry over; the registrar is matched to your imported vendor by name.
Certificates	Certificates	Linked to their imported client and domain. A certificate with no expiry date is skipped and logged (an expiry is required).
Networks	Networks	Linked to their imported client (orphans skipped). Subnet, gateway, VLAN, DNS servers and the DHCP range carry over; the network's location is linked when it was imported.
Technicians (users)	Users	Each ITFlow technician imports as a disabled placeholder user (it cannot sign in) so it can own the tickets and time entries they worked. If the technician's email already belongs to a member of this Ascent org, the import links to that existing member instead of creating a duplicate.
Tickets	Tickets	Linked to their imported client (a ticket with no imported client is skipped and logged); the contact, assignee and creator are linked when those records were imported. Priority maps to Ascent's priority (defaulting to Medium); the ticket status is matched to one of your ticket statuses by name (an unmatched status imports the ticket without a status and is flagged in the report); the source maps to Ascent's source (defaulting to Manual). The subject, description, billable flag and created date carry over.
Ticket replies	Ticket replies	Linked to their imported ticket (orphans skipped), with the author linked when imported. Replies import as internal notes unless ITFlow marked them public.
Time entries	Time entries	Linked to their imported ticket. The author is required — a time entry whose technician was not imported is skipped and logged. Minutes, the billable flag and the date carry over.
Products / services	Products	Imported at the organization level. The ITFlow type (service / product) maps to Ascent's product type; the product code becomes the SKU; price carries over; a product with a tax is marked taxable; archived products import as inactive.
Recurring invoices	Recurring invoices	Linked to their imported client (orphans skipped). The billing frequency (e.g. Month, 3 Months) maps to Ascent's billing cycle (unrecognized values default to Monthly and are flagged); the next-run date is required (a schedule without one is skipped and logged); the active flag carries over.
Quotes	Quotes	Linked to their imported client (orphans skipped). The status maps to Ascent's quote status; dates and currency carry over. The original quote number is preserved in the notes. Totals are recalculated from the line items, so the imported quote always foots.
Invoices	Invoices	Linked to their imported client (orphans skipped) and to their recurring schedule when it was imported. The status maps to Ascent's invoice status, then is refined to Partial / Paid based on the payments imported below. Dates and currency carry over; the original invoice number is preserved in the notes. Totals are recalculated from the line items.
Quote / invoice line items	Quote / invoice items	Linked to their imported quote or invoice (orphans skipped) and to the imported product when one is referenced. Each line's amount is recalculated from quantity × unit price; if that disagrees with the figure stored in ITFlow, the line is flagged in the report for review.
Payments	Payments	Applied to their imported invoice (orphans skipped). The payment method maps to Ascent's method (unrecognized values import as Other); the payment date carries over. As payments are applied, the invoice's amount-paid and status are updated — fully paid invoices become Paid (dated by the latest payment), partially paid ones become Partial.
Documents / knowledge base	Documents	ITFlow's documents are its knowledge base, so this brings over all of it — runbooks, SOPs and client-facing articles alike. The document body (rich text) carries over as-is. A document tied to a client links to that imported client; a company-wide document imports with no client (and one whose client wasn't imported still comes across, flagged in the report, rather than being dropped). The "visible in client portal" setting is preserved. Re-running updates existing documents instead of duplicating them.
File attachments	Files	Imported only when you upload an attachments archive (see Importing file attachments). Files attached to an asset, document or quote are re-hosted and linked to that record; contact-only and client-only files are skipped (Ascent has no place to attach them) and files missing from the archive are logged. Re-running re-hosts nothing already imported.

Anything the importer can't attribute (e.g. a contact, asset, ticket, line item or payment with no imported parent) is surfaced in the run report rather than dropped silently.

Cleaning up

Deleting a migration run removes its staging data, id map, logs, the stored encrypted credentials (live-database source) and the stored encrypted backup file (backup source) — use it once a migration is complete. For a backup migration the uploaded file is also removed automatically as soon as the run finishes, and whenever a run is cancelled.