Hello Ray, thank you very much for your quick answer and the explanation.

But I must say that I don't think that this is the right way. The aim of designing a realtional database should always be to avoid redundant data and before, Odoo was very good in it. A "Contact"-contact for examplae has no postal adress, but instead refers to the postal adresse of the parent company contact. Very good. If the company is moving, only one dataset has to be edited.

Now let's say there is a contact "Andreas Brinkmann" as a contact at the "Company Ltd." and as you suggest, we verate another contact "Andreas Brinkmann" holding his mobile number. In CRM-App you can only connect one contact with a chance. So, when you try to reach Andreas by phone and he doesn't answer you have to navigate with the internal link to "Andreas Brinkmann (Phone) -> "company" -> "Andreas Brinkmann (mobile)" to take another try.

Well, let's imagine, not you, but one of your collegues reached him finally on his mobile. And at the end of the call he tells you, that he changed his job. Still working for Comany Ltd. but from now on three days a week from his home office. Therefore you should note his private number and therefore you must create a third contact for the same person.

As time goes by, after several weeks someone is talking to him on his private phone number and gets the information, that he is now married and changed his name to "Andreas Someone". You are now forced to investigate how many contacts "Andreas Brinkmann" exists and change them all to the new name.

I bet a hundred EURO that the quality of the datasets will get bad because no one is doing this. Especially in a hectic office situation while working on a telephone marketing campaign.

There must be another solution.

Hope you have a nice day
Andreas Brinkmann (still me :-) 

I agree that this is a problem for many companies who will be forced to add back a custom field for mobile to avoid losing data.
I think a better solution would have been to keep the field but to hide it in the view based on certain logic, but removing the field entirely was not good practice IMO.

Someone marked this thread as "solved" but I can't find any solution for it. I administrate an Odoo databases at our company with something about 50k contacts and I guess something about 30% of them contains more then one phone number. That means lost of data within 15.000 datasets with an update to v18.2. And the need to create 15.000 new datasets of contacts, just to store the mobile number by copy paste processing from the chatter.

Not to mention all the sh... of things from my first answer. So, where is the solution?

Create a new custom field, move the mobile phone numbers prior to migration. You can then script the creation of new contacts.

Run this 3 times:

partners_with_mobile = env['res.partner'].search([('x_mobile', '!=', False)],limit=5000)

for partner in partners_with_mobile:
new_partner = env['res.partner'].create({
'name': partner.name + " (Mobile)",
'phone': partner.x_mobile,
'type': 'contact',
})
partner['x_mobile'] = False

Hello Ray,

It's commendable that you're trying to offer a personalized solution here. But that can't change the fact that this approach is fundamentally wrong.

I'll just list my thoughts on this.

1. Your approach assumes the "Custom" license is being used, as Studio is only available there.

I manage a second database for a nonprofit organization that wanted to save the additional costs for Studio. This organization maintains contacts across Europe, and it's essential that we store multiple phone numbers for one contact. These contacts work in local governments for a limited time, but their roles also change. To maintain an overview, we must avoid creating redundant contact details.

2. You suggest naming the second contact "Name (mobile)." But if there's only one mobile number, do I enter it in the phone number field? Do I create another contact for this? Do I enter the mobile number in the phone field? What do I do if I subsequently receive a landline number? New contact - copy the mobile number over - enter the landline number. If the procedure is not clear from the design of the database, the database is set up incorrectly.

3. If the contact is of type "Other Address", how can I ensure that the other address is updated in the "Original Contact" and not in the Contact (Mobile) (see also 2. for this). Ambiguous approach = Wrong database design

4. New contact means there's also an "Email" field. How do I ensure that only one email address is entered here if the original contact doesn't have one yet? How do I ensure that a change is reflected everywhere? If I only enter the address for one contact, I can't send a message for processes that reference the other contact (opportunities).

5. There's already a field called "Street" and "Street2." Based on the current reasoning, this would also have to be eliminated and separated into a second data set if necessary, right?

My suggestion: Why doesn't Odoo simply leave the field where it is and recommend the method with a second contact record "Name (Mobile)" for anyone who has problems with multiple phone number fields? They can leave the "Mobile" field blank. So nobody has to loose data within an update.

I understand everything you are posting. There is a lot I agree with.

Nothing I posted requires Odoo Studio.

I work in the part of Odoo that helps people understand and use what we have, even when it is "incorrect" and "wrong" and "a problem" and "not good practice" and "fundamentally wrong".

I sympathize but can only recommend you work out how to live with this change.

Our own internal sales team requested we revert this change and that request was declined, so the chances of it being "corrected" are almost none.

I am also having the issue with no having more than one number. Iphone, Android and ever other ERP system in the world allows you to have multiple numbers for Office, Fax, Cell, Home, etc. How can this not be a standard feature in a software that markets based on Automation and user simplicity. Odoo Version 18 Online could be one of the great ERP system in history if they would just add some of the most common things... So frustrating... 

Ok. Thanks for removing my replies, I'll just post it again since I do not receive any proper response from Odoo yet.

TL;DR

After upgrading from 18.0 → 18.2, the mobile phone field in Contacts is gone. This causes lost/hidden data and breaks CRM/CTI integrations and day-to-day operations. Please revert this change and implement a proper solution (e.g., the “which number” logic proposed by Ray Carnes) that preserves existing data and behavior.

What happened

We performed a test upgrade from 18.0 to 18.2 and discovered that the mobile number previously stored on contacts is no longer available as before. Our CRM/telephony (CTI) relies on matching any known number (landline or mobile) to a single person. With 18.2 this no longer works.

Business impact

CTI/CRM pop-ups fail: incoming calls no longer resolve to the correct person when they use their mobile instead of the office line.

Chatter fragmentation: the suggested workaround—splitting one person into multiple contacts (one for landline, one for mobile)—destroys history continuity. Notes made when the client calls the office line are not visible when they later call from mobile, and vice versa.

Operational confusion: colleagues can’t find the full context (previous notes, tickets, orders, etc.) tied to a single human being.

Data integrity & reporting: duplicating people to carry different numbers pollutes the database and degrades reporting accuracy.

Integrations: existing API/CTI mappings expect a consistent per-person model with multiple phone numbers.

Why this is problematic

It’s a backwards-incompatible data model change in a minor point release (18.0 → 18.2) with major usability and integration impact.

The proposed “duplicate contacts” workaround is misaligned with real-world usage where one person has multiple numbers.

It burdens customers to remodel their data and re-engineer integrations for no functional gain.

Requested resolution

Revert the removal of the mobile phone field (or any equivalent behavior change) and restore compatibility in 18.2.x.

If the long-term goal is to normalize phone numbers, implement a first-class multi-number model (e.g., numbers with a type: mobile, landline, direct, fax) while:

Preserving existing data (no loss),

Maintaining backwards compatibility (aliases/redirects/migration scripts), and

Providing clear “which number” logic and a primary number flag for CTI/CRM.

Communicate a proper migration path (deprecation notice, tooling, and docs) ahead of any future version where behavior would change.

Until a fix is available, 18.2 is a no-go for us because it disrupts daily operations and breaks our CRM/phone integration.

—

Environment: Odoo 18.0 → 18.2 (test upgrade)

Integrations affected: CTI/phone, CRM, tickets/orders

Call to action (for other affected users)

If you’re impacted, please add your voice so this is prioritized:

Open a support ticket with your Odoo Partner/Odoo Support titled

“18.2 Regression: Mobile phone field removal breaks CRM/CTI & fragments chatter.”

Include: your business impact (missed caller identification, fragmented chatter, duplicate contacts), version details (18.0 → 18.2), and a request to restore the mobile field or ship a compatible multi-number model with ‘which number’ logic.

Ask your Partner to link your ticket to the broader regression and escalate.

Copy-paste template for tickets:

Title: 18.2 Regression — Mobile phone field removed from Contacts breaks CRM/CTI & fragments chatter

Description: After upgrading from 18.0 to 18.2, the mobile phone field/behavior in Contacts changed, breaking caller identification and CRM/CTI pop-ups. The suggested workaround (splitting one person into multiple contacts) fragments chatter history and harms data integrity.

Impact: Caller identification fails across landline vs mobile; colleagues can’t see full history; integrations break; upgrade blocked.

Request: Revert the change in 18.2.x and/or implement a backward-compatible multi-number model (with number types and “which number” logic), preserving existing data and APIs.

Environment: 18.0 → 18.2 (test upgrade). Integrations: CTI/CRM.

Priority: High – upgrade on hold pending resolution.

Since making this change, we've helped over 50,000 customers either upgrade to or implement Odoo 18.2, Odoo 18.3, and Odoo 18.4. We've found that most users have been able to adapt without needing to customize it. However, we know that every business is unique, and what works for the majority might not work for you. Please contact Odoo Support at odoo.com/help to have them walk you through how to use either the Notes field or to add a new field to store this information.