There are projects in which the technical challenge and the business challenge are exactly the same problem formulated from different perspectives. The case of Rehabmedic is one of them. It involved launching a new business unit — the rental of medical rehabilitation equipment — with a tight go-live deadline, a legacy infrastructure not dimensioned to support the projected growth, and the need for organic positioning from day one. What follows is the technical and business description of how it was resolved.
The challenge: zero visibility, fragile infrastructure, fragmented platform
A new business unit with no digital presence
Rehabmedic is a company in the health and rehabilitation equipment sector with a consolidated presence in its market. When launching the medical equipment rental unit — a segment distinct from sales, with its own commercial process, its own billing logic and its own target audience — there was no specific digital presence for that service. The potential customer searching on Google for «rent articulated bed» or «electric wheelchair rental» did not find Rehabmedic. Visibility was literally zero.
The opportunity cost was immediate and quantifiable: every week without positioning was a week of demand going to the competition. There was no time to build domain authority organically over months; the right technical lever had to be found to accelerate indexing and positioning from the very first moment.
Legacy infrastructure without high availability
The existing infrastructure presented a risk profile incompatible with the projected growth. Failure points were identifiable: no database replication, no automatic failover mechanisms, no proactive observability. A system outage during a traffic peak or a customer acquisition campaign had no guaranteed recovery time.
For a company in the health sector where customers may be searching for equipment urgently — hospital discharge, post-operative recovery — downtime has a direct cost in user experience and, consequently, in conversion and reputation.
Fragmented platform: Navision and Magento as the starting point
The starting technology stack consisted of two systems that also did not communicate smoothly:
- Microsoft Dynamics NAV (Navision) for ERP management: accounting, inventory, suppliers and the sales business operations.
- Magento as the e-commerce platform, largely disconnected from the ERP, with manual data synchronisation or through fragile integrations.
The new rental unit could not be built on top of this architecture without first addressing the integration. And the real integration demanded asking whether it made sense to maintain three separate platforms — Navision, Magento and a new rental system — or consolidate on a unified architecture.
The solution: Odoo Multi-web, Schema.org and real high-availability architecture
Odoo Multi-web as a unified platform
The central architectural decision was to consolidate on Odoo as a single platform, leveraging its Multi-web module to independently manage the sales store and the new rental portal from the same instance. This approach offered concrete advantages:
- A single source of truth for inventory: a product could be available for sale and rental simultaneously, with unified stock management.
- Differentiated processes in the same system: the rental workflow — contract, deposit, return, periodic billing — was implemented as an extension of Odoo's native modules, without the need for an external system.
- Specific web for each business unit: the rental portal had its own domain, its own visual identity and its own content architecture, but ran on the same Odoo instance with access to the same ERP.
Schema.org: the lever for accelerated positioning
Here lies the technical heart of the positioning result. The question that had to be answered was: how does a new website — without domain authority, without backlinks, without history — achieve Top 3 positions on Google for commercial keywords in less than 60 days?
The answer did not lie in conventional content SEO. It lay in the Schema.org structured data architecture implemented from day one on every product page of the rental portal. The logic is as follows: Google may take months to develop trust in a new domain, but it can trust almost immediately a site that speaks its language — and the language Google prefers for understanding content is Schema.org.
The following markup types were implemented:
- Product with
offers,availability,priceValidUntilandaggregateRatingon each rental product page. - Organization with complete company information, contact details and links to social networks.
- LocalBusiness with geographic service area and availability hours.
- FAQPage on category pages, answering the most frequently asked questions about the rental process.
- BreadcrumbList throughout the navigation hierarchy to facilitate crawling and structural understanding of the site.
The result was that Google could understand, from the first crawls, exactly what each page was, what product it offered, at what price, with what availability and in what geographic area. Without ambiguity, without inference. Rich snippets appeared in the results almost immediately, which increased the organic CTR and fed back into the positioning.
«A well-built ERP is not just internal operations: it is also a positioning machine when data flows correctly all the way to the web layer.»
High availability: live PostgreSQL replication
To address the infrastructure risk, a high-availability architecture with real-time PostgreSQL streaming replication was designed and implemented. The key elements:
- Live PostgreSQL replica: a secondary server continuously receives the WAL (Write-Ahead Log) from the primary, maintaining an up-to-date copy in real time. If the primary node fails, the replica can be promoted to primary in a controlled time.
- Load balancing for reads: read-only queries — the majority of web traffic — are distributed between primary and replica, reducing the load on the main server.
- Supervised failover: the replica promotion process is documented and tested, with a defined and reproducible recovery time.
This architecture ensured that during traffic peaks — campaigns, seasonal hospital discharges, events — the system maintained performance without perceptible degradation for the end user.
Observability with Telegram bots
The observability component deserves specific mention because it was one of the elements that made a difference in real operations. A system of proactive alerts via Telegram bots integrated with system monitoring was implemented. The approach was pragmatic: it is not about having the most sophisticated dashboard, but about ensuring that when something fails or is about to fail, the responsible person knows within seconds, not hours.
The alerts cover multiple layers:
- Server load and memory usage with configurable thresholds.
- PostgreSQL replica status: replication lag, WAL receiver connection, synchronisation queue length.
- Critical errors in Odoo logs: worker crashes, database timeouts, cron job failures.
- Website availability: periodic HTTP checks with immediate alert if response time exceeds the threshold or the site returns an error.
The result is a proactive operations posture: problems are detected and resolved before the end user experiences them.
Migration from Navision and Magento
The migration from Navision to Odoo was planned as a phased process to avoid total operational cut-over. Accounting, inventory and customer management were migrated with a controlled parallel operation period, validating data integrity at each stage before disconnecting the source system.
The migration from Magento presented the typical challenge of this type of platform: a product and category data schema with its own structure that does not map directly onto Odoo's model. Specific transformation scripts were developed for product masters, categories, order history and registered customers, with cross-record validation to ensure referential integrity.
The success criterion for both migrations was the same: zero operational downtime. The store was not closed at any point during the process. Orders during the migration period were processed without interruption.
Results: real metrics
Organic Top 3 on Google in 60 days
The most striking result and the one that generates the most questions: Rehabmedic's rental portal reached Top 3 on Google for the target keywords in the Spanish market in less than two months from launch. Without paid advertising investment. Without a link building campaign. Solely with the correct technical architecture: complete Schema.org from day one, optimised page load speed, clean URL structure and well-described product content.
This result is not reproducible by applying any standard SEO tactic. It is the result of the platform — Odoo with a well-implemented structured data architecture — speaking to Google in a way that Google understands and rewards.
Zero downtime during traffic peaks
During the post-launch operating period, including traffic peaks from campaigns and moments of high seasonal demand, the platform maintained full availability. The live PostgreSQL replica absorbed the additional read load without impact on the primary node's performance. Telegram alerts allowed minor incidents to be resolved proactively, before they reached the end user.
Unified platform operational
Replacing Navision and Magento with Odoo eliminated the operational friction of managing multiple systems. The operations team works on a single interface for inventory management, billing, CRM and web content. The maintenance cost of two additional systems — licences, integrations, training — disappeared from the P&L.
Technical lessons applicable to your project
1. Schema.org is not an SEO detail: it is data architecture
Most teams treat Schema.org as an on-page optimisation element added «when there is time». In projects where organic visibility is critical from launch, Schema.org must be part of the platform design, not a subsequent adjustment. If Odoo is your platform, the product data already exists in the ERP: it just needs to flow correctly to the HTML markup.
2. High availability is not optional for businesses with demand peaks
PostgreSQL streaming replication is neither an exotic nor expensive architecture. It is the correct response to the risk of business loss from system outage. The cost of implementing it is far lower than the cost of an outage during a traffic peak in a sector where customer urgency is real.
3. ERP migration must be invisible to the end customer
A migration process that shuts down the store for hours or days has a direct cost in sales and reputation. Planning the migration in phases, with parallel operation and clear validation criteria before each cut-over, is the only way to ensure the end customer does not notice the change.
4. Proactive observability is cheaper than reactive recovery
A Telegram bot that alerts when the PostgreSQL replica has been lagging for more than 30 seconds costs hours of configuration. A database outage incident without proactive monitoring can cost days of recovery and measurable business losses. The cost-benefit ratio is obvious.
5. Odoo Multi-web allows scaling business units without multiplying operational complexity
When the business grows and a new product line, a new geographic market or a new distribution channel appears, the usual response is to add another platform. With Odoo Multi-web, the answer is to add a new site on the same instance, with access to the same ERP and the same data, without duplicating the infrastructure or multiplying maintenance costs.
Do you have a similar project?
If you have a new business unit launch project, a pending Navision or Magento migration, or an infrastructure not ready for the next level of growth, I can review your situation and tell you what architecture makes sense for your specific case. No smoke and mirrors. No 80-page proposals that take three months to execute.