We lift your vTiger CRM from 5.x, 6.x or 7.x to vTiger 8.4 – character set, custom code and integrations included, and with a target stack that respects the end-of-support dates of PHP and your database. You know the cost before we start, and you get it in writing afterwards that every record arrived.
An ageing vTiger installation rarely fails with a bang. It falls behind step by step: first the mailbox connection, then your hoster’s PHP version, and finally the upgrade path itself.
The mail connection breaks first
Microsoft disabled basic authentication for IMAP and POP in Exchange Online back in October 2022, Google followed on 30 September 2024. For SMTP submission via Microsoft 365, the timeline updated in January 2026 applies: basic auth is switched off by default for existing tenants through the end of 2026, new tenants no longer get it at all afterwards, and Microsoft will announce the final removal date in the second half of 2027. OAuth2 for mailboxes only exists in the vTiger 8.x line – older releases lose mailbox access, and mail scanner and outbound mail simply stop.
Vulnerabilities keep being published
Old vTiger versions no longer receive security updates – new vulnerabilities are still published for them, most recently CVE-2025-1618 for vTiger 6.4.0. The entries for 7.1.0 (CVE-2019-11057, SQL injection) and 7.5.0 (CVE-2023-38891, privilege escalation via ReportRun.php) have been open for years. The stack underneath is end-of-life too: PHP 7.4 has had no security fixes since November 2022.
Every skipped release adds cost
vTiger cannot be lifted from 5.x to 8.x in one jump – the path runs through the intermediate releases, each with its own migration patch. And PHP has to move in lockstep: vTiger 6.x only runs on PHP 5.6, 7.5 on PHP 7.3 up to 8.1 at most, and only 8.4 supports PHP 8.3. Upgrading PHP ahead of the CRM does not rescue the old system, it shuts it down.
The stack underneath moves on
PHP 8.1 reached end of life on 31 December 2025, PHP 8.2 only receives security fixes until 31 December 2026, and extended support for MySQL 8.0 ended on 30 April 2026. That is exactly what hosting providers are migrating their environments to right now. A target stack that ignores those dates turns into another project within twelve months.
Our offer: migration from any vTiger version
We migrate any vTiger version to the current release – from early 5.x installations through 6.x and 7.x up to vTiger 8.4.
Whether you run an untouched standard installation or a system grown over years with its own modules, workflows and integrations: we take a close look at your setup before we touch it. What comes along technically is listed here – including the points where a vTiger migration typically breaks, and not buried in the small print of a quote.
The version chain step by step: 5.x → 6.x → 6.5 → 7.x → 8.x using the official migration patch for each step, applied and verified individually
PHP moved in lockstep with the version chain: 5.6 for 6.x, 7.2–7.4 for the 7.x line, 7.3–8.1 for 7.5, 8.1–8.3 for vTiger 8.4 – no release ever runs on a PHP version it was not released for
Database converted to utf8mb4: umlauts, ß and double-encoded legacy data are cleaned up instead of carried over
Tables moved from MyISAM to InnoDB, keys and sql_mode adjusted – the legacy vTiger setting NO_AUTO_CREATE_USER no longer exists as of MySQL 8.0.11 and otherwise aborts the migration run
Database target chosen with its end of support in mind: MySQL 8.4 LTS or a MariaDB LTS series instead of the expired MySQL 8.0
The migration run itself made viable: memory_limit, max_execution_time and the database privileges (CREATE, ALTER, DROP) set so the script completes instead of stalling halfway
Custom code and custom modules ported to PHP 8.3 – including the spots that only surface at runtime
Core modifications moved onto supported extension points, so the next vTiger patch is an update again rather than a project
Mailbox connection rebuilt: OAuth2 for Microsoft 365 and Google, mail scanner and templates
Extensions inventoried: anything no longer available for vTiger 8 is replaced or rebuilt – with the effort quoted up front
Workflows, roles, profiles, numbering, templates, customer portal and cron jobs
Document archive and attachments including directory structure, paths and file permissions – not just the database
Connections to ERP, shop, telephony and web forms brought over and tested
How your migration works
A four-step approach built on more than ten years of vTiger projects – while your day-to-day business keeps running without interruption.
1
Analysis
Free initial assessment of your installation: version, data volume, character set, PHP and database level, customizations, extensions and integrations. You receive a written migration report – naming the target version, the end-of-support dates of your current PHP and database version, the vulnerabilities published for your release, and a binding effort estimate. Even if you decide not to continue with us.
2
Migration
We pull a copy into a staging environment and work through the version chain step by step, including the character set conversion and porting your custom code. Every step is written down so the run stays repeatable – go-live is not a premiere later on. Your production system stays untouched throughout.
3
Testing
You test with real users and real data in staging. We supply the test cases per module and integration and record what was verified – only then do we agree on a cutover date.
4
Go-live
Cutover at your preferred date, in the evening or at the weekend if you prefer: the rehearsed run against a fresh copy of your data, record reconciliation, reconnected mailboxes and functional checks. The rollback point stays in place until you sign off.
How to spot a predictable migration
Migration offers all sound alike. These six points are the difference between a promise and a migration you can verify.
Pricing before you call
The day rate and three effort examples are on this page, not behind a form. After the free initial assessment you get a binding estimate; additional effort only ever happens once you have approved it.
Evidence instead of assurances
Go-live includes an acceptance report: record counts per module before and after the migration, workflows verified, integrations tested. What you hold at the end is a document, not just a promise.
A target stack with a shelf life
We do not migrate to some vague “latest”, but to a dated combination: vTiger 8.4 (July 2025) on PHP 8.3 with a database that is still in support. Core modifications move onto supported extension points – so the step to vTiger 8.5 stays an update instead of turning into a second project.
Your data stays in Germany
Analysis, test migration and go-live are done by the same team in Trier, Germany – reachable Monday to Friday, 8 a.m. to 5 p.m. CET, in German or English. Data processing agreement under Art. 28 GDPR, German contract law, NDA on request – and no handover to subcontractors outside the EU.
The way back stays open
Until you sign off, your production system remains untouched. A defined rollback point is agreed for go-live day, and the old system stays available read-only for as long as you need it.
You stay independent
Your vTiger open source installation stays yours: no move into a cloud, no per-user licence, no obligation to use our extensions. Operations can stay with your current hoster, and documentation, migration log and credentials belong to you.
Transparent pricing
We bill by actual effort at a day rate of €1,200 net. The following three scenarios show the typical effort depending on your starting point. After the free initial assessment you receive a binding effort estimate for your installation – additional effort only ever happens with your prior approval.
Billed by effort · day rate €1,200 net
Example 1
Standard migration
For standard installations without custom modules
€1,800 – €3,000
1.5–2.5 days
Migration report covering version, PHP and database level including their end-of-support dates
Backup and test migration in a staging environment
Character set conversion to utf8mb4 including umlaut clean-up
Migration of all standard data (contacts, organizations, deals, tickets, documents including the file store)
Go-live with record reconciliation and acceptance report
Example 2
Migration with customizations
For systems with custom modules, workflows, and integrations
€3,600 – €6,000
3–5 days
Everything in the standard migration
Migration of custom modules, workflows, user roles, and profiles
Extension inventory incl. replacement recommendation for anything no longer available for vTiger 8
Integrations verified and reconnected: mailboxes via OAuth2, telephony, web forms
Example 3
Complex custom migration
For custom code, large datasets, and third-party systems
€8,400 – €14,400
7–12 days
Everything in the migration with customizations
Porting of custom code to PHP 8.3 and the current codebase, with core modifications rebuilt on supported extension points
Migration of large datasets including the document archive
Integration of third-party systems (ERP, shop)
Optional: maintenance contract
Included in every scenario
Free initial assessment with a written migration report and a binding effort estimate
Recommendation for the target version, PHP and database level including their end-of-support dates
Test migration in a staging environment – production stays untouched until you sign off
Acceptance report with a record count per module
Defined rollback point on go-live day
Go-live in the evening or at the weekend if you prefer
Data processing agreement under Art. 28 GDPR, delivery from Germany, NDA on request
Typical project duration of 2–3 weeks
Additional effort only with your prior approval
Deliberately not included
Licence and subscription fees for third-party extensions
Server, hosting and certificate costs of your environment
Moving your hoster to the required PHP and database version – we supply the specification for it in writing
Content-level data clean-up such as deduplication – available as separate effort
End-user training and process consulting – available as separate effort
New features that did not exist in your old version
All prices net, plus statutory VAT.
Frequently asked questions about vTiger migration
The key answers up front – everything else is covered in your free initial assessment. All version, price and deadline figures on this page are as of August 2026.
How much does a vTiger migration cost?
We bill by effort at a day rate of €1,200 net. A standard migration without custom modules typically runs €1,800 – €3,000, a migration with custom modules and integrations €3,600 – €6,000, and complex custom migrations with own code and third-party systems €8,400 – €14,400. After the free initial assessment you receive a binding effort estimate for your installation.
How long does a vTiger migration take?
The pure effort is between 1.5 and 12 person-days depending on complexity, with a typical project duration of 2 – 3 weeks. Your day-to-day business keeps running throughout, because we work in a staging environment first and only cut over at the agreed date – in the evening or at the weekend if you prefer.
Will any data be lost during the migration?
No – and we prove it rather than just promising it: before the cutover we take a backup and run a test migration in a staging environment that you review together with us. Go-live includes an acceptance report listing the record counts per module before and after the migration, plus the workflows and integrations that were verified.
Which vTiger version do you migrate to?
To the current stable open source release of the 8.x line; since 9 July 2025 that is vTiger 8.4, recommended with PHP 8.3 and MySQL or MariaDB (as of August 2026). No release date has been published yet for an 8.5. Which target version fits your extensions and your hoster is documented in the migration report.
Which versions can be migrated – can 5.x go straight to 8?
We migrate from any version: vTiger 5.x, 6.x and 7.x. Technically there is no direct jump, though – the path runs through the intermediate releases (5.x → 6.x → 6.5 → 7.x → 8.x), each with its own migration patch. On top of that comes the PHP staircase: vTiger 6.x only runs on PHP 5.6, the 7.x line on PHP 7.2 to 7.4, 7.5 on PHP 7.3 to 8.1, and vTiger 8.4 is released for PHP 8.1 to 8.3. We work through both chains in lockstep and verify after each step instead of pushing the database through in a single pass.
Is my old vTiger version still secure?
Old vTiger versions no longer receive security updates – yet vulnerabilities keep being published for them, for vTiger 6.4.0 as recently as 2025 (CVE-2025-1618). The entries for 7.1.0 (CVE-2019-11057, SQL injection) and 7.5.0 (CVE-2023-38891, privilege escalation) have been open for years, and PHP 7.4 has had no security fixes since November 2022. For a system holding customer data that is an avoidable risk – the migration report lists the vulnerabilities published for your specific release.
What happens to the mail connection to Microsoft 365 or Google?
We set it up again. Microsoft disabled basic authentication for IMAP and POP in Exchange Online in October 2022 and Google followed on 30 September 2024. For SMTP submission via Microsoft 365 the timeline updated in January 2026 applies: through the end of 2026 basic auth is disabled by default for existing tenants and can only be re-enabled by an administrator, new tenants no longer receive it afterwards, and Microsoft will announce the final removal date in the second half of 2027. Older vTiger releases have no OAuth2 support and lose mailbox access; on the current version we reconnect mailboxes, mail scanner and outbound mail via OAuth2.
Are custom modules, workflows and custom code migrated too?
Yes. Custom modules, workflows, user roles, profiles, numbering and templates are migrated, and custom code is ported to PHP 8.3 and the current codebase. We do not just test that it starts: your real processes are exercised in the staging environment, because the spots that only surface at runtime are the expensive ones.
What about extensions that are no longer available for vTiger 8?
We inventory them during the initial assessment. For every extension the migration report states whether it is available for vTiger 8, will be replaced by an alternative, or has to be rebuilt – including the effort. That way you decide before placing the order, not halfway through the project.
Will umlauts and special characters be correct after the migration?
Yes, because we convert the database properly to utf8mb4. Old vTiger installations often carry a mix of latin1, utf8 and HTML entities; without that conversion an upgrade turns them into permanently broken characters. We also clean up double-encoded legacy data instead of carrying it over.
Where is my data processed during the migration?
Exclusively in Germany. Analysis, test migration and go-live are handled by our team in Trier under a data processing agreement pursuant to Art. 28 GDPR and German contract law; we sign an NDA on request. Nothing is handed to subcontractors outside the EU.
What happens if something goes wrong at go-live?
A defined rollback point is agreed for the cutover day: your production system stays untouched until sign-off, and if the functional checks turn up something that does not fit, your team keeps working on the old system. It also stays available read-only after go-live for as long as you need it.
Which PHP and database version does vTiger 8.4 need?
vTiger 8.4 is released for PHP 8.1 to 8.3; we target PHP 8.3, because PHP 8.1 reached end of life on 31 December 2025 and PHP 8.2 only receives security fixes until 31 December 2026. Worth knowing for conversations with your hoster: PHP 8.4 is not released for vTiger 8.4 – a well-meant PHP upgrade can take the CRM down. For the database we recommend MySQL 8.4 LTS or a MariaDB LTS series, since extended support for MySQL 8.0 ended on 30 April 2026.
Should we wait for vTiger 8.5?
No. No release date has been published yet for an 8.5 (as of August 2026). The open source cadence has recently been one to two releases a year: 8.0 in September 2023, 8.1 in January 2024, 8.2 in May 2024, 8.3 in September 2024, 8.4 in July 2025. Once you are on 8.4 you are inside the 8.x line – a later step to 8.5 would stay an update during a maintenance window, not another migration across several version steps.
Can we run the migration ourselves?
Technically yes – the migration patches are freely available. In practice the time does not go into applying them but into the pitfalls: the sql_mode entry NO_AUTO_CREATE_USER that vTiger expects and MySQL dropped in 8.0.11; a migration run that aborts on memory_limit or max_execution_time; missing CREATE, ALTER and DROP privileges; mixed character sets; and the PHP version that has to match each step. You can also use the free migration report as the basis for doing it in-house – we will tell you plainly whether having us alongside is worth it for you.
What happens to customizations made directly in the vTiger core?
We bring them along – in a way that survives the next update. During the port, changes to the core are rebuilt on supported extension points (custom modules, event handlers, overrides) instead of being patched into the source again. That is typically the reason the last upgrade never happened; every such spot is documented in the acceptance report.
Does vTiger 8.4 still receive security updates?
Yes – and that is precisely the difference to a legacy release. Vulnerabilities are reported for the 8.x line as well, for instance CVE-2025-70936 affecting vTiger 8.4.0, but they get fixed in the next release. On a maintained release a security advisory is a maintenance window; on a discontinued version it is a permanent condition.
Do we have to move to vTiger Cloud afterwards?
No. Your vTiger open source installation stays your system – no per-user licence and no forced cloud subscription. Operations can stay with your current hoster; on request we take over maintenance or operations, and documentation and credentials belong to you either way.
Do you work outside Germany?
Yes. We run migrations remotely across Germany, Austria, Switzerland and Luxembourg – access happens through your environment, coordination by video and phone, in German or English. On site we cover Trier and the Rhineland-Palatinate, Eifel and Greater Region Luxembourg area.
Ready for vTiger 8?
Request your free initial assessment. Helpful for a quick start: your vTiger version, the rough data volume, your PHP and database version and who hosts the installation today – we clarify the rest in a call. You receive the written migration report together with a binding effort estimate, with no obligation and no risk.
