UnitBase & Scriptum to Odoo Migration Services

UnitBase migrations are primarily data-structure problems. The work involves mapping flat registries to Odoo's relational model, transforming field types, and cleaning data that accumulated without integrity constraints. Scriptum migrations are primarily process problems — the data volume is usually smaller, but the work involves analyzing approval routes, condition logic, and script triggers, then reconstructing them in Odoo's automation layer without breaking the underlying business logic. Projects migrating from both platforms combine both scopes.

A focused migration covering 5–10 registries with no custom module work runs 4–6 weeks from audit to go-live. A full migration including Scriptum workflow reconstruction, integration rebuilds, and a parallel-run period typically runs 10–16 weeks. The main variable is specification completeness at kickoff — projects where existing workflows are poorly documented add 30–50% to the timeline.

No. Active history from the past two to three years is imported as mail.message records in Odoo, visible in the Chatter panel of each document. Older history is exported to structured PDF or JSON archives and linked from Odoo's Documents module. References to users who have since left the company are handled by creating archived profiles with the original actor noted in the message body.

It depends on what UnitBase and Scriptum were doing. If UnitBase was managing financial records requiring full double-entry accounting, you probably need Enterprise — Community does not include Odoo's full Accounting module. If UnitBase functioned as a document registry without direct accounting integration, Community may cover your needs. We provide a written comparison of Enterprise vs. Community gaps relevant to your specific workflows before you commit to either. For a full breakdown, see our Odoo ERP development services.

Those integrations need to be rebuilt. We audit every existing connection during the pre-migration phase, document the data flow and API contract for each, and rebuild them as proper Odoo connectors. Depending on whether the external system uses webhooks, polling, or bulk file exchange, the rebuild approach varies. We scope each integration separately with its own estimate.

Odoo runs on PostgreSQL and scales to tens of millions of records with proper indexing. For datasets above 5M rows, we add targeted database indexes on filtered fields, evaluate whether heavy reporting queries should run direct SQL via env.cr.execute() rather than through the ORM, and configure materialized views refreshed via ir.cron for dashboard queries. Performance is tested in the staging environment before any cutover decision.

UnitBase lookup fields map to Odoo's fields.Many2one type, which creates a proper relational link between records. During migration, we import all referenced objects — contacts, products, categories — first, then import parent records with the correct relational IDs. This two-pass import ensures referential integrity on load. Where UnitBase allowed free-text lookup values with no corresponding master record, we flag those for client review during the data audit; they cannot be migrated directly without a decision on how to handle them.

Your team operates in both systems simultaneously during parallel run. Sales orders, approvals, and transactions entered in one system are cross-checked in the other daily. We maintain a shared discrepancy log and resolve issues in Odoo before the decommission date. The parallel run requires extra effort from your operations team — typically two to four weeks. That overhead is worth it: it is the only reliable way to confirm Odoo handles every real-world edge case before the old system is turned off.

Four inputs: your current platform (UnitBase, Scriptum, or both), the approximate number of registries or active workflows, any external systems currently connected to the platform, and your target Odoo version. If you already have a data dictionary or workflow documentation, scoping moves faster. If not, we offer a paid discovery phase that produces the migration specification — that document becomes the basis for the fixed-price contract.

Yes. We offer monthly maintenance retainers covering bug fixes, minor workflow adjustments, and Odoo security patch compatibility. Retainer scope is a fixed number of developer hours per month allocated against a logged backlog. We also support version upgrades when your Odoo installation needs to move from v17 to v18 or v19 — because migrations happen more than once.

Usually not. "Too complex to migrate" is almost always a scoping problem, not a technical one. The real work is documenting what the workflow does — including all exception states — and reconstructing it in Odoo's automation layer. Workflows that look complicated in UnitBase's metadata interface frequently simplify when written as Python Server Actions, because you can write direct conditionals instead of working around platform constraints. Cases that genuinely require custom module development are buildable — just at higher cost than standard configuration work.