1. Multi-tenant architectures inside of applications is a proven way to keep data separate. Every relevant table/model should have a tenant_id column on it indi

1. Multi-tenant architectures inside of applications is a proven way to keep data separate. Every relevant table/model should have a tenant_id column on it indicating what customer that data is tied to. Indexes on that column and unit test coverage to setup two tenants and try to access each other's data should help convince management. If they want the company and app to grow, they aren't going to want to spend a 6 month project collapsing 100 to 1000 databases and dealing with databases out of sync, etc. Its a maintenance nightmare to have a database per customer at the volume of users you have. I work on systems with 1000's of customers and sharding has not come up at all. 2. Use the Strangler Fig Pattern (aka strangler pattern) to slowly rewrite the app in small iterations with a feedback loop. Write a new component that slowly takes over the old component and brokers between the two until the old one is, well, choked out. You state you're running docker, so figure out what the new tech stack is, call it new_stack (the tech choice here doesn't really matter for a web app and this pattern): - deploy a docker container running nginx, and new_stack - deploy a second docker container with the old PHP stack on it (old_stack) - setup nginx on new_stack to proxy all HTTP requests to both containers - at first it proxies everything to old_stack container - rewrite some full service part of app in new_stack and change the proxy rules to route traffic to new_stack for that service - repeat the last step for each part of the app as its rewritten - if you run into major issues, update the nginx rewrite rules to route back to old_stack. DigitalOcean and CloudFlare probably have features to do what I describe above, I don't have details but look into load balancers where you can shard traffic to different servers based on the HTTP route.