Managed MySQL fit
Compatible on paper
MySQL 8.0, 320 GB minimum storage, private bare-metal connectivity, two nodes, automatic failover, asynchronous replication, 14-day backups and a 99.95% Production SLA. Available in both RBX and ERI.
OCI → OVH migration dossier
Know the estate.
Choose the exit.
A decision-ready view of the current Oracle estate, the live Magento codebase, and the two credible OVH landing patterns. Two physical servers fit the measured load; the real choice is paying OVHcloud to operate MySQL or operating a three-member database cluster ourselves.
Control plane 2026-08-23
Guest probe 2026-08-24
Region eu-frankfurt-1
Live code scan 2026-08-24
Guest probe 2026-08-24
Region eu-frankfurt-1
Live code scan 2026-08-24
8→2OCI VMs → Rise hosts
63.3GB production MySQL
1.75TB live Magento media
96app/code modules
£6912 Rise-3 + managed DB
£3213 Rise-3 self-managed
Two servers are enough
Measured CPU and RAM use, the 63.3 GB database, and the proven `jade` hardware class all support two Rise-1 or Rise-3 hosts. With OVH Managed MySQL, a third physical database member is unnecessary.
The remaining tradeoff
Managed MySQL removes database patching and failover work but more than doubles platform cost versus three self-managed Rise-3 nodes. Guest inspection is now complete across all eight servers; the remaining work is migration rehearsal, database import compatibility and security cleanup.
Choose the operating model
The applications fit on two physical hosts. The selector isolates the consequential choice: managed database operations versus the lowest monthly cost.
Preferred · lower operations risk
£690.78monthly · ex. VAT
Servers £213.94
Managed MySQL £476.84
Two 12-core hosts leave ample application headroom while OVHcloud operates the two-node MySQL service and automatic failover. Add a small independent witness for Proxmox quorum and Redis Sentinel.
Physical compute2 × Rise-3 · 24 cores · 128 GB RAM
DatabaseOVH Managed MySQL · 2 × 15 GB nodes
ResponsibilityOVH patches, backs up and fails over MySQL
Known subtotals exclude VAT, the small quorum witness and independent backup. The newer Production B3-16 managed tier is about £560.20/month; the comparison uses the still-listed 15 GB Business DB1-15 at about £476.84/month. Confirm availability and checkout price before ordering.
Schema gate removed
16 tables no longer block HA
Those tables block MySQL Group Replication because they lack row identity. OVH's managed topology uses ordinary asynchronous replication, so this is not an initial migration blocker.
Still prove it
No purchase before rehearsal
Import a clone, validate all 84 triggers and definers, exercise checkout/admin/cron, benchmark RBX/ERI latency, and force a managed failover.
01Provision private test service
02Import the 63.3 GB clone
03Validate triggers and definers
04Benchmark Magento workflows
05Force failover and restore
The Magento application is code plus state
The live checkout was inspected over read-only SSH. The source is manageable; generated output, local working data and the NFS media corpus must be handled as separate migration streams.
/var/www/html/aashni
- app/code96 modules · 81 MB · migrate/audit
- app/designMgs/ethan + mgsblank · 6.9 MB
- composer.json + composer.lock488 packages · rebuild
- vendor624 MB · reinstall from lock
- generated109 MB · regenerate
- pub/static312 MB · regenerate
- var8.8 GB · classify; mostly runtime state
- media6.0 GB local · reconcile before deletion
- pub/media → /aashnimedia/media~1.75 TB live NFS media
Two checkouts, one commit
The 17 GB live tree and 2 GB /var/www/html/aashni_git repository are both on master at 29a610cab68c410c0c96605f3a6198d19adbf5db.
Build the OVH image from a sanitized canonical repository. Do not copy the 17 GB tree wholesale: its generated code, logs, imports, PDFs, local media and scripts obscure the small source payload and include unsafe tracked artifacts.
Runtime: Magento Community Edition 2.3.5-p1, Nginx 1.18, PHP-FPM 7.2 and Solr 7.7.3. Preserve this legacy runtime for the infrastructure cutover; upgrade only after migration stability.
Company-specific catalog, API, invoice and data-update behavior.
The largest custom family; checkout, merchandising, fulfilment and admin workflows.
Native-app APIs, page layout and Solr-linked presentation logic.
Payment integration code that needs checkout and callback rehearsal.
Small catalog/category schema and presentation customization.
Direct Composer requirements also include Stripe PHP, Facebook SDK, Mailchimp, Liquid and Mirasvit search/sorting.
!
Urgent owner-authorized cleanup is required before migration
The repository tracks private-key material named .key, Test.key and aashni_new_ssh. The last file contains a private-key marker and is mode 0644. No secret contents were read or copied into this report.
pub/adminer.phpandpub/config.phpare tracked under the public root; current public checks returned 404.pub/100020273_AJODEC2102A_purchase_order.pdfis tracked and returned HTTP 200 publicly. Treat it as exposed: remove it from origin/history as appropriate, purge caches and assess notification obligations.- Tracked working-tree changes include key files and five
Aashni/ProductUpdatefiles; generated code is also noisy. Capture legitimate changes into a clean repository before building OVH guests. - Rotate every discovered private key and any credential it could unlock. This report does not perform remote deletion, cache purging or rotation without explicit authorization.
Application stack and data flow
All eight compute nodes are guest-confirmed. Green paths are verified application and data flows; amber annotations identify migration decisions or intentionally limited content-level inspection.
This HTML dossier is the primary report. Raw Markdown, CSV and OCI evidence remain local and are deliberately excluded from the shared deployment.
How Aashni traffic flows
The current load balancer exposes HTTP and HTTPS, then routes requests to the staging, public website and admin/backend servers.
Public traffic
Internet
HTTP + HTTPS
Protection
aashni-waf
Active web firewall
Traffic director
aashni-elb
150.230.149.165 · 80 / 443
Staging
stage.aashniandco.com
aashni-stage
aashni-stage
Website
aashniandco.com + www
aashni-prod-frontend
aashni-prod-frontend
Admin / API
/admin_backend + /magminer
aashni-prod-admin
aashni-prod-admin
MySQL 8.0.46 · 10.0.1.14
Magento Redis · 10.0.0.16
OCI Redis 7.0 · not referenced by live admin config
This route is confirmed from load-balancer rules. Journal and Revivify are not attached to this load balancer.
Eight running servers
36 OCPUs and 108 GB of memory in total. All eight use the E4 Flex shape and run in Frankfurt availability domain 1.
Aashni
4 servers · Ubuntu
aashni-prod-frontend
Magento 2 production storefront and media
6OCPUs
24 GBMemory
2,298 GBTotal disk
Guest verified: Magento 2.3.5-p1 · Nginx · PHP 7.2/8.1 · Redis 7.4 · Varnish · NFS media server · four Magento checkouts.
aashni-prod-admin
Magento 2 admin and backend routes
6OCPUs
24 GBMemory
550 GBTotal disk
Guest verified: Magento 2.3.5-p1 · Nginx 1.18 · PHP-FPM 7.2 · Solr 7.7.3 · MySQL schema and NFS media path captured.
aashni-stage
Magento 2 staging storefront
4OCPUs
16 GBMemory
550 GBTotal disk
Guest verified: Magento 2.3.5-p1 · Nginx/Apache · PHP 7.2/8.1 · Varnish · three code trees; 500 GB data disk is unmounted.
Journal-wordpress
Journal WordPress site
2OCPUs
8 GBMemory
47 GBTotal disk
Guest verified: WordPress on Nginx/PHP 8.3 with local MySQL · 9 plugins · 10 themes · about 6 GB under /var/www/journal.
Revivify
4 servers · Ubuntu 24.04
Revivify-prod
React admin dashboard + Express production API
8OCPUs
16 GBMemory
297 GBTotal disk
Guest verified: three PM2 services · five Node repositories · local MySQL · 43.3 GB used on the 250 GB /mnt/data volume.
UAT-Revivify
Node.js/Express beta API
4OCPUs
8 GBMemory
147 GBTotal disk
Guest verified: four PM2 services · five Node repositories · local MySQL; the 100 GB /data volume is nearly empty and code remains on boot.
Revivify-Jenkins
Build and deployment automation
2OCPUs
4 GBMemory
147 GBTotal disk
Recovered and guest verified: Jenkins 2.528.2 · 96 plugin archives · 5 jobs · Nginx · Java 17; SSH is private-subnet/Bastion-only.
Revivify-WordPress
Revivify WordPress site
4OCPUs
8 GBMemory
147 GBTotal disk
Guest verified: WordPress on Nginx/PHP 7.4 with local MySQL · 11 plugins · 7 themes · about 310 MB under the web root.
Data and storage
OCI shows one managed relational database, one managed cache, 104 MySQL recovery points and 16 attached disks. Guest topology also exposes a separate Redis service and NFS media export on the frontend VM.
aashni-prod-db-1
OCI MySQL DB System · Active
MySQL 8.0.46
- Endpoint
- 10.0.1.14:3306
- Database shape
- MySQL.2 · single node
- Storage
- 150 GB · auto-expand to 500 GB
- Backups
- 7 days · PITR on · 104 found
- High availability
- No
- HeatWave cluster
- 1 × HeatWave.512GB · active, no observed use
Read-only guest discovery identified schema aashniproddb: 620 tables/views, 52.0 GB data, 11.4 GB indexes and 84 triggers. mst_sorting_cl alone holds about 32.5 GB. OCI Monitoring recorded zero HeatWave statements and zero data-load progress over the 90 days ending 24 August 2026.
aashni-redis
Managed Redis cache · Active
Redis 7.0
- Topology
- Non-sharded · 1 node
- Memory
- 16 GB
- Primary endpoint
- 10.0.1.227
- Node endpoint
- 10.0.1.146
- Replica
- None
- Backups found
- None
The managed cluster has no replica, but the live admin Magento configuration does not reference it. Cache DBs 0/1 and session DB 2 point instead to Redis on aashni-prod-frontend at 10.0.0.16.
Disk allocation by server
| Server | Boot | Attached data volumes | Total |
|---|---|---|---|
| aashni-prod-frontend | 50 GB · code/runtime | 200 GB mounted but effectively empty + 2,048 GB media at 86% shareable | 2,298 GB |
| aashni-prod-admin | 50 GB · 68% used | 500 GB attached but unmounted and absent from fstab | 550 GB |
| aashni-stage | 50 GB · code/runtime | 500 GB formatted but unmounted | 550 GB |
| Journal-wordpress | 47 GB | — | 47 GB |
| Revivify-prod | 47 GB | 250 GB mounted at /mnt/data · 43.3 GB used | 297 GB |
| UAT-Revivify | 47 GB · code/runtime | 100 GB mounted at /data · 274 MB used | 147 GB |
| Revivify-Jenkins | 47 GB · Jenkins home | 100 GB not used by the running guest | 147 GB |
| Revivify-WordPress | 47 GB · site/runtime | 100 GB not used by the running guest | 147 GB |
| Fleet total | 385 GB | 3,798 GB | 4,183 GB |
No boot-volume, block-volume or volume-group backups were returned by OCI. The managed MySQL backups do not protect files stored on these VM disks.
Network and edge
Two separate virtual networks serve Aashni and Revivify. Every VM currently has a public IP address.
Virtual networks2 · aashni-vcn, RevivifyVCN
Subnets4 · 2 public, 2 private
VNICs / private IP objects12 / 14
Internet gateways2
NAT / service gateways1 / 1
Load balancer1 public · 3 backends
Web application firewall1 active policy + WAF
VPN path1 DRG + 1 IPSec connection
User-managed DNS zones0
Network security groups0 attached to VMs
Network firewallPolicy only · no firewall
Seven guests still expose public SSH
Both public VCN security lists allow TCP/22 from 0.0.0.0/0; Aashni also allows it over IPv6. Jenkins now blocks public SSH in UFW and permits port 22 only from its private subnet/Bastion path.
Database port exposure rules
Revivify’s default list allows MySQL/3306 from anywhere. The Aashni private-subnet list allows 3306 and 33060 from anywhere, though route placement still limits reachability.
All VMs have public addresses
Eight public IPs increase the migration and hardening surface. The load balancer only fronts three Aashni servers.
Firewall policy is not enforcement
An empty network-firewall policy exists, but no OCI Network Firewall instance is deployed.
People and access
There are 2 OCI IAM users—not 4. The identity domain also contains 37 mostly Oracle-created application integrations; these are not people or workloads.
| OCI IAM user | Status | Created |
|---|---|---|
| akash@aashniandco.com | Active | 4 Jun 2024 |
| vishal.doshi@gmail.com | Active | 22 Aug 2026 |
IAM structure
Control-plane access
- Groups
- Administrators; All Domain Users
- Policies
- 3 active
- Identity domain
- 1 active default domain
- Identity applications
- 37 · 34 active
Fleet SSH and OCI recovery access
| Access path | Coverage | Verified position |
|---|---|---|
| GitHub RSA key SHA256:4oGiwu…pinIM | All 8 guests · ubuntu | Installed and used |
| OCI Bastion · Aashni subnet codex-key-recovery-20260824 | Frontend, admin, stage, Journal | Active |
| OCI Bastion · Revivify subnet codex-key-recovery-revivify-20260824 | Prod, UAT, Jenkins, WordPress | Active |
| Oracle Cloud Agent Bastion plugin | All 8 guests | Running 8 / 8 |
Dashboard recovery is now durable. The four original launch-key comments remain historical metadata, but a locally matched GitHub RSA public key is present in every guest. OCI does not inject a newly edited instance-metadata key into an already-running OS; the two retained Bastions are therefore the panel-managed recovery route. Jenkins deliberately accepts SSH only from 10.0.1.0/24, so it remains reachable through the Revivify Bastion without exposing port 22 publicly. All temporary Bastion sessions and the serial-console recovery connection were deleted after verification.
Certificates and operations
Monitoring exists around the Aashni frontend and admin servers. Certificate objects include two old, expired imports that remain marked active in OCI.
| Certificate | Covers | Valid until | Status |
|---|---|---|---|
| aashniandco-2025 | aashniandco.com, www | 29 Sep 2026 | Current |
| aashni-ssl-2024 | aashniandco.com, www | 29 Sep 2025 | Expired object |
| aashni-letsencrypt | *.aashniandco.com | 15 Oct 2024 | Expired object |
4 alarms
All active
Warning and critical load alarms for aashni-prod-frontend and aashni-prod-admin.
3 logs
1 log group
WAF activity plus load-balancer access and error logs.
2 alerts
Email subscriptions
Notifications go to Akhilesh and Akash through one topic.
Object Storage1 flow-log bucket · 22 objects
Lifecycle / replicationNone on the bucket
Custom compute images1 · aashni-image-05092024
MySQL recovery7-day backups + PITR
What is absent—and what is unknown
“Not found” means the authoritative OCI service API returned no tenant-owned resource. “Unknown” means OCI cannot see inside a server or database.
No resources found in these OCI services
Base DatabaseAutonomous DatabaseNoSQLPostgreSQL
File StorageOKE / KubernetesContainer InstancesContainer Registry
FunctionsAPI GatewayDevOpsIntegration
Network Load BalancerNetwork Firewall instanceFastConnect
Vault / KMS keysSecretsStreamingQueues
Event rulesService ConnectorsResource ManagerInstance pools
AutoscalingCapacity reservationsDedicated hostsUser DNS zones
Guest inventory complete; migration validation remains
Clone-import production MySQL into OVH Managed MySQLValidate triggers, definers and Magento workflowsInventory local MySQL schemas with application ownersTrace external APIs from sanitized configuration
Confirm Revivify upload retentionReconcile Magento's 6 GB local media copyDecide fate of three unused data disksTest backup restores, not only backup creation
Rotate tracked private keysRemove public PDF and exposed admin utilitiesFix stage/uat certificate routingChoose two managed-DB hosts or three self-managed hosts