Migrate from Oracle or SQL Server to PostgreSQL without rewriting the app

No, and that is exactly the point of the project. Data is migrated with integrity validation (counts, checksums, foreign keys) and is not accepted until it matches the source row by row. Functionality is preserved by converting the stored logic (PL/SQL, T-SQL) to PL/pgSQL and proving parity with a test suite before turning the old engine off. The few things PostgreSQL solves differently —a proprietary type or a particular analytic function— we map to their equivalent and document for you; we do not let them drop silently.

No. The goal of this migration is to change only the database engine, not the system. In most cases the app change is limited to the connection driver and a handful of SQL dialect differences; for applications on SQL Server, Babelfish for PostgreSQL speaks the same protocol and reduces even further what has to be touched. If your application is already on an obsolete language or framework and you want to modernize it, that is a separate, complementary project: our Legacy modernization (also in the software factory), which can run in the same phase as, or after, the engine migration.

It is quoted by effort, at our factory base rate of $600 MXN per hour, which drops with the volume of hours committed. The real cost depends on the size of the schema, how much stored logic (procedures, triggers, packages) has to be converted and the dialect differences — that is why we start with a bounded-scope Database migration assessment: it delivers the compatibility report, the risk map and an effort estimate per object, and it is yours even if you decide not to continue with us. No invented fixed packages: first we measure, then we quote.

PostgreSQL is open source: it pays no engine license or per-core support like Oracle or SQL Server, so that line disappears from your bill. How much that represents in your case depends on your current contract, your edition and your licensing model; we will not invent a percentage for you. The honest version is this: you eliminate the engine license cost, and against that you put the one-time cost of the migration and the cost of running PostgreSQL (a team or a managed service). In the assessment we help you build that TCO comparison with YOUR numbers, not with a brochure case.

It is a very common combination and it makes total sense: a managed PostgreSQL like Amazon Aurora or Azure Database for PostgreSQL usually costs a fraction of the proprietary license, and the engine change is the natural moment to do it. Even so, these are two distinct intents: changing the ENGINE (what we do here) and moving the INFRASTRUCTURE to the cloud. When the project includes the latter, we coordinate it with our Cloud migration (Azure/AWS) from the Cloud & DevOps mini-site, which brings the landing zone, the network and the 6R model. You can do just the on-premise engine change, or both in a single wave.

Yes. PostgreSQL runs high-volume OLTP and analytical workloads with partitioning, advanced indexing, MVCC concurrency, read replicas and extensions for special cases. Part of the project is precisely to prove it before cutover: in the proof of concept we measure the real performance of your heaviest queries on PostgreSQL and, if something is slow, we tune it (indexes, plans, parameters) until it matches or beats the engine you are leaving. We do not migrate on faith: we migrate with parity and performance metrics on the table. If you then want to exploit that data with analytics and dashboards, that is Data engineering and BI, another factory capability.