Organization-specific setup
Configuration is per organization. Company details, currencies, tax rates, and document numbering are set before master data is loaded.
Review configurationData before tools
Start with the records the business is prepared to stand behind.
Migration is not simply a file upload. Duplicates, missing references, inactive values, inconsistent identifiers, old statuses, and unclear ownership can move into the new system just as easily as clean data. The customer should decide what is authoritative and what success means before anything is loaded.
How a migration runs
Use four control points from source inventory to cutover.
Every migration follows these steps. The customer owns the data and the acceptance; the team loads the data and reports what was rejected.
- 01Customer data owner
Inventory and classify
List source systems, datasets, owners, record volumes, history, attachments, dependencies, sensitive fields, and exclusions.
- 02Customer preparation
Clean and map
Remove known errors and duplicates, define identifiers, map fields and reference data to BusinessIntents, and approve the prepared files.
- 03Team and customer
Load and reconcile
The team loads a test set and reports rejected rows; the customer compares counts, totals, links, and statuses against the source.
- 04Customer decision
Approve and cut over
Freeze changes in the old system, load the final set, confirm acceptance, and start working in BusinessIntents.
The migration scope and quotation record who does each step, the records in scope, and the acceptance checks.
The destination
Prepare the destination before any data is loaded.
The product guides describe the records the data lands in, so preparation can start before the scope is agreed.
Continue your numbering
Document counters are visible and adjustable under Settings, so invoices and other documents can continue from the last number in your previous system.
Review document numberingCheck the result in lists
Every list exports to CSV with the current filters, which makes it easy to compare the loaded records with the source.
Review list and export behaviorAcceptance checks
Reconcile the result at business-record level.
Technical completion is not enough if totals, references, statuses, ownership, or access are wrong. Validation should follow the decisions that matter in daily work.
Completeness
Compare expected and loaded records, rejected rows, required fields, attachments, and historical periods.
Accuracy and relationships
Check identifiers, amounts, dates, currencies, taxes, units, links, statuses, owners, and opening positions where relevant.
Usability and access
Confirm that the right roles can find, interpret, update, approve, report, and export the migrated information.
Migration scope
What a BusinessIntents migration covers.
Every migration is agreed individually. These are the points each scope settles, and how they are normally handled.
Supported sources and formats
The team works from files the customer exports from the old system, normally Excel or CSV. There is no ready-made connector to another system; if a direct extraction is needed, it is analysed as part of the scope.
Records, history, and attachments
A typical scope covers master data, such as customers, suppliers, products, employees, and stores, and opening positions, such as stock quantities and account balances. Whether open documents, history, or attachments are migrated is agreed in the scope.
Customer data preparation
The customer extracts, cleans, and deduplicates the data, maps it to the BusinessIntents records, and approves the files before they are loaded. The team can advise on the structure the files need.
BusinessIntents responsibilities
The team reviews the files, loads them in bulk into your environment, reports rejected rows and their reasons, and repeats the load after corrections, all within the agreed scope.
Security and privacy
Data is loaded only into your own database in AWS Frankfurt, by authorized codbex personnel. The transfer route for files is agreed before any personal or financial data is sent. Processing on your behalf is covered by the Data Processing Agreement.
Volumes and performance
There are no published volume limits. The team estimates the work from the record types, row counts, and data quality described in your request, and the estimate is part of the quotation.
Testing and reconciliation
A test load comes first. The customer checks record counts and control totals, such as customer balances, stock quantities, and the trial balance, and the team corrects and reloads until the customer accepts.
Cutover and rollback
The customer chooses the cutover date, freezes changes in the old system, and the team loads the final set. Until you accept the result, the old system stays your system of record, so you can postpone the go-live if a check fails.
Adoption decisions
Connect migration to implementation, support, and data governance.
The migration uses the same responsibilities, security facts, retention rules, and acceptance model published on these pages.
Rollout
Implementation
Connect data readiness to configuration, testing, training, and go-live.
Open page →OperationsSupport
See how issues after the migration are reported and resolved.
Open page →InfrastructureData Hosting
Review processing locations, access, backups, logs, and deletion.
Open page →Personal dataPrivacy
Review legal roles, purposes, transfers, retention, and rights.
Open page →Migration questions
Confirm the scope against the actual source data.
Which systems and file formats can BusinessIntents migrate?
The team works from files the customer exports from the old system, normally Excel or CSV. Any system that can export its data to such files can be a source; there is no ready-made connector to a specific system.
Who prepares and validates the data?
The customer extracts, cleans, and maps the data and accepts the result. The team loads it, reports rejected rows, and reloads after corrections, within the agreed scope.
Should we send production data during evaluation?
No. Use the demo's sample data during evaluation. Live personal or financial data is sent only through the transfer route agreed for the migration.
What happens to migration files after completion?
The files are used only for the migration. How long they are kept and when they are deleted is set out in the migration scope and the Data Processing Agreement; you can ask the team to delete them once you accept the migration.
Prepare the data decision
Describe the source before asking for a migration estimate.
Bring the systems, records, volumes, quality issues, history, and acceptance requirements that shape the real work.
Describe the source system, the records, and the approximate volumes at office@codbex.com. Do not attach live personal or financial data; the team agrees a transfer route with you first.