Coming across from another system
The migration cockpit: what comes over as records, what is archived instead, and why the cutover is a series of dated rounds rather than one weekend.
Bringing a company across is a project rather than an import, and the cockpit under Platform → Legacy Migration is built around that. It knows about more than thirty source systems — ERP, CRM, HRMS, healthcare and student systems — and what each of them calls the things TRANXACT has its own names for.
The rule that shapes everything
Master data and OPEN transactions come across as real records, through the application, obeying every rule. Closed history is archived rather than re-posted. Re-posting three years of paid invoices would produce three years of journals into periods that are closed, and a trial balance that no longer agrees with the one you signed off.
Two phases
- The plan: what is coming, from where, mapped field by field against what the target actually accepts — read from the product rather than guessed.
- The rounds: dated delta loads that run again and again while the old system is still live, each one bringing across what changed since the last, until somebody calls the cutover.
Each round is a record. What it found, what it created, what it refused and why — and a reset that puts a round back if it was wrong. A migration you cannot re-run is a migration you only get one attempt at.
Opening balances
The closing trial balance of the old system becomes an opening journal in the new one, dated to the day before you go live. That is the only accounting entry the migration makes, and it is the one that has to be right.
Where the files come from
An unload from a real system is routinely larger than anything anybody wants to attach to a browser upload. Point the migration at a connected drive and it is read where it stands — see Connected drives.
Every step has a Template download: an empty spreadsheet with the columns its field map reads. Where a map accepts a field under more than one name — a QuickBooks ledger export may head its date column "Transaction date", "Date" or "Trans Date", depending on the report — the template carries one column for each alternative, so whichever export you have, its column is on the template.
SAP Business One
SAP Business One (SAP-B1 in the system list) comes across in thirteen steps, each named after the B1 tables it is read from, and in the order the cockpit runs them: the things a transaction points at exist before the transaction does.
| Step | Read from | Comes across as |
|---|---|---|
| Chart of accounts | OACT, postable accounts only | GL accounts. Title accounts are the drawers of the chart and nothing can be posted to them. |
| Cost centers | OPRC, dimension 1 | Cost centers. B1 calls them profit centers; its other dimensions are separate lists. |
| Vendors | OCRD where CardType is S | Suppliers |
| Customers | OCRD where CardType is C | Customer accounts. Leads (CardType L) are pipeline, not customers. |
| Items | OITM with OITB | Items, stock and non-stock alike |
| Open purchase orders | OPOR with POR1, open lines | Purchase orders for what is still to be received |
| Open A/R invoices | OINV, open | Customer invoices, with what has already been received settled |
| Open A/P invoices | OPCH, open | Supplier invoices, under the vendor’s own invoice number |
| Closed A/R invoices | OINV, closed | Archived history, never re-posted |
| Closed A/P invoices | OPCH, closed | Archived history, never re-posted |
| Incoming and outgoing payments | ORCT and OVPM | Archived as evidence |
| Trial balance | JDT1 summed per account | The opening journal |
| Ledger history | OJDT with JDT1 | The journals over the period you keep |
The source record carries the extraction aids: the query for Microsoft SQL Server and the same query for SAP HANA, the B1 client menu paths when you would rather export from the client (Query Manager to Excel, Business Partner Master Data, Items List, General Ledger, Trial Balance, Aging), and a script for the Service Layer at https://<server>:50000/b1s/v1/ where the database itself cannot be reached. The field maps are seeded against the column names those exports produce, so a file straight out of B1 maps without being renamed.
The trial balance is summed from the journal lines rather than read off B1’s Trial Balance report, because the report interleaves title-account subtotals that would have to be stripped out before anything balanced.
Is it ready? The readiness dashboard
The cockpit is worked one step at a time. The question asked in a go-live meeting is a different one: are the customers ready, are the open payables ready, is the stock ready. Platform → Legacy Migration → Migration Readiness answers it per business area and across every system being left, and the cockpit’s header has a Readiness dashboard button that opens it.
At the top is one figure for the whole cutover — the share of what is in scope that is ready — with a verdict beside it (Ready for go-live, In progress or Not ready), the records brought across, the data quality, the exceptions and how many objects are Ready, in Review and Blocked. Below it is a tile for each business area; choose one to see only that area, or All areas.
| Area | What it covers |
|---|---|
| ERP — finance and core masters | Customers, vendors, materials, open A/R, open A/P, fixed assets, the chart of accounts, cost centers, opening balances, ledger history and closed transactions. |
| CRM — customers and pipeline | Accounts, contacts, leads, open opportunities, open quotations, open sales orders, open cases, campaigns and activity history. |
| SCM — supply chain and logistics | Suppliers, items and units, warehouses and bins, put-away and replenishment rules, stock on hand, open purchase orders, open warehouse work, carriers and tariffs, open freight, and plans and forecasts. |
| Manufacturing | Work centers, bills of material, routings, equipment and maintenance plans, inspection plans, open production and maintenance orders, open quality events, and plant history. |
| HR and payroll | Organization and positions, employees, dependents, pay structure, recurring pay elements and payroll history. |
| Healthcare | Patients, providers and departments, payers and policies, problems, allergies and immunizations, future appointments, active prescriptions, open encounters and clinical history. |
| Student lifecycle | Programs and courses, students, transcripts, open applications, current enrollments, student accounts and aid, holds and registration history. |
| Staffing and contingent workforce | Clients and programs, candidates, open job orders, open submissions, active placements, timesheets and invoices, and compliance items. |
Each area is a table with one row per thing it has to bring across:
| Column | What it says |
|---|---|
| Records | The rows in the extract — the newest upload of each step that feeds the row, added up across every source system being left. |
| Quality | The share of those rows that passed the target screen’s own checks. |
| Exceptions | The rows refused, by the checks or by the screen when they were loaded. Open the step in the cockpit to read why each was refused. |
| Reconciled | Yes when every stage of the step is done, no row is still waiting to be loaded, and every record the cockpit created is still there. No when some of those records have since been deleted. Pending otherwise. |
| Status | Ready, Review, Blocked, Not started, Not declared or Not applicable — see below. |
| Status | When |
|---|---|
| Ready | Quality is 98% or more and the row is reconciled. |
| Review | Quality is between 90% and 98%, or the row is not reconciled yet. |
| Blocked | Quality is below 90%, or records the cockpit created are no longer there. |
| Not started | A system being left has this step, and nothing has been uploaded to it yet. |
| Not declared | No system being left brings this across. The row says which other systems’ plans do. Either declare it on the system that holds it, or confirm the business has none of it. |
| Not applicable | The step was skipped because this company has none of it. |
Choose a row to see what it covers and which steps, from which systems, feed it. One step can feed two areas — a customer list is both the ERP’s customers and the CRM’s accounts — and the totals at the top count it once.
An area appears once a system being left brings anything into it. The areas nobody is bringing anything into are listed at the bottom as not part of this cutover. A system counts as being left once a file has been uploaded to it or one of its steps has been skipped.
Before anything has been uploaded there is nothing to measure. Illustrative, beside This company, shows the dashboard with sample figures for a demonstration, marked on the page as not the company’s own. The sample figures never mix with the real ones.
Who may do what
The cockpit and the readiness dashboard are granted per role under Platform → Roles, as Migration Cockpit and Migration Readiness, and every action in the cockpit asks for the permission it needs:
| Permission on Migration Cockpit | Lets somebody |
|---|---|
| Display | Open the cockpit and read the plan, the steps, the mapping, the rows and the tie-out. |
| Add | Upload an extract — from this computer, from a connected drive or as a scheduled upload. |
| Change | Check, load, post, settle, archive, post balances or the ledger history, skip or redo a step, set the numbering, the approach and the rounds, and mark the cutover complete or reopen it. |
| Delete | Discard a staged file, or reset the whole cutover. |
Migration Readiness needs display only; it changes nothing. The lists behind the cockpit — Source Systems, Migration Objects, Field Maps, Migration Batches, Migration Runs, Migration Resets, Archived History and Opening Balances — are granted separately, like any other screen.
Two roles ship ready to assign:
- Migration Lead runs the cutover: every permission on the cockpit, add, change and delete on Source Systems, Migration Objects and Field Maps, and display on the readiness dashboard and the other lists.
- Go-live Reviewer reads the readiness dashboard, the cockpit and every list behind them, and changes nothing — for the steering committee, the auditor or the business owner signing the cutover off.
Somebody whose role may read the cockpit but not change it sees a note saying so under the progress bar, and the cockpit refuses any change they try. Each screen’s button to the other only shows to people who may open it.
Marking the cutover complete closes the cockpit and the lists behind it for that company, and nothing else. Every other Platform screen keeps working as before.