You can do this! It is a little work. It sounds like you are able to deploy your own infra, and it sounds like you are not making any writes to the db. These

You can do this! It is a little work. It sounds like you are able to deploy your own infra, and it sounds like you are not making any writes to the db. These two factors make the app significantly easier, versus needing to hold writes (and deal with reads to that augmented database) until the backing db comes back online. (CRDTs are a nice way of expressing growing a database over time, but an old old corporate DB sounds like some mess in SQL.) The main principle is that you're going to serve queries from your own system, and your system is informed by $OLD_DB. You're going to have, ultimately, a `last_updated_at` attribute on everything you know. You're going to, ultimately, stream all of $OLD_DB into $NEW_DB. If a DB query to $OLD_DB is over HTTP, then the query bodies are a bit larger and slightly ungainly and very easy to cache; by sticking a caching proxy in front of that HTTP endpoint and telling it to keep EVERYTHING and serve stale content and looking at the headers that come back, now you have database queries that can be as stale as necessary.