– Database migrations
Database migrations
with a tested path
to cutover.
We assess compatibility, prove critical assumptions, rehearse the
migration and define rollback criteria before production changes.
Oracle to PostgreSQL. Major version upgrades. On-premises and cloud migrations.
– When migration becomes necessary
When the current platform
becomes a business constraint
Licence and operating costs
The cost of the existing platform no longer reflects the value it provides, and proprietary dependencies limit realistic alternatives.
Data does not move reliably
Your current version is approaching end of support, but the upgrade affects applications, extensions, infrastructure or availability requirements.
Your analytical platform must scale
A cloud programme, data centre exit or infrastructure change requires databases and connected workloads to move without disrupting critical operations..
You need control and trust
Multiple database platforms, versions and operating models increase cost, security exposure and operational complexity.
Application modernisation
Legacy SQL, stored procedures, reporting logic and integration patterns prevent the application from evolving.
Whatever starts the migration, the decisive questions are usually the same: what must change, what must remain compatible, how downtime will be controlled, and what evidence is required before cutover.
– Proof, not promises
An anonymised client engagement
Situation
A business-critical financial-services application relied on Oracle for transactional processing and operational reporting.
Challenge
The migration required SQL and reporting compatibility, controlled production cutover and a clear rollback decision before the source system could be retired.
Baremon's work
We assessed dependencies, converted and optimised critical SQL, validated application and report results, prepared the cutover runbook and defined rollback criteria.
Outcome
The system was migrated to PostgreSQL and stabilised in production. Application and reporting results were validated before cutover, operational runbooks were transferred to the internal team, and SQL for selected reporting workloads was modernised and optimised.
Planning a similar transition? Request an initial migration review →
– Migration readiness assessment
Turn migration uncertainty into a decision-ready plan
Before you commit to a target platform, budget or cutover date, we assess the
source environment, application dependencies, compatibility, data movement
options and operational constraints.
The assessment identifies the recommended path and the evidence still required. It
does not assume that migration is always the right decision. If we continue with
delivery, the assessment becomes the first phase of the migration.
What you receive from the assessment
- Migration complexity and risk summary
- Source and application dependency findings
- Target options with documented trade-offs
- Recommended migration and cutover approach
- Indicative effort and timeline
- Proof-of-concept recommendations
- Clear go/no-go decision points
Vendor-neutral assessment. Deliverables your team can use independently.
Senior-led migration delivery when you need it.
– Our migration approach
Five phases. Defined outputs. Explicit decision points.
We analyse the source environment: workloads, SQL and code compatibility, data volumes, dependencies, operating constraints and recovery objectives.
Outputs: assessment report, risk register, effort estimate and target options – including high-level target architecture, sizing assumptions, resilience requirements and operating-model trade-offs.
Critical assumptions are tested early – compatibility, performance of representative workloads, tooling and conversion approach.
Outputs: PoC results, benchmarks, compatibility findings, go/no-go decision.
We migrate to a test environment, validate data integrity and compare application and report results between source and target. Dual run is not always required – it is used where the risk profile and operating constraints justify the additional complexity.
Outputs: test matrix, comparison results, performance baseline, recovery validation.
Cutover follows a written runbook with timed steps, verification points and predefined rollback criteria. The go/no-go decision is made against evidence, not optimism.
Outputs: cutover runbook, rollback plan, communication plan, executed cutover.
We monitor the new environment, resolve early operational findings and transfer knowledge to your team.
Outputs: monitoring setup, operational runbooks, documentation, practical handover sessions.
– Migration risk
Six questions that determine migration risk
1
Where is platform-specific logic located?
Not only in the database. It may also be embedded in application SQL, reporting tools, ETL jobs, scripts and monitoring.
2
How will changes be synchronised during migration?
For larger systems, the decisive issue is often not the initial data load but keeping source and target consistent until cutover.
3
How will equivalence be demonstrated?
Row counts are not enough. Applications, reports, calculations, permissions and operational behaviour may all require validation.
4
What workload must the target sustain?
A technically compatible database can still fail the migration if representative production workloads have not been benchmarked.
5
What is the real downtime budget?
The acceptable window determines tooling, replication strategy, rehearsal requirements and rollback options.
6
Who has authority to stop the cutover?
Go/no-go criteria are ineffective unless decision ownership is agreed before the production window begins.
If several of these questions remain unanswered, implementation is premature. Start with an initial review to determine the appropriate assessment scope.
– Cutover & rollback
A cutover plan must also explain when to stop
Most migration plans describe how to move forward.
Ours also define when and how to move back.
Proceed
All entry criteria are met. Data validation, workload checks and operational readiness support the production change.
Pause
A required result is incomplete or ambiguous. The cutover does not proceed until the evidence is available.
Roll-back
A predefined threshold is breached. The team follows the agreed rollback procedure rather than improvising under pressure.
Rollback criteria, the downtime budget and decision ownership are agreed in writing
before the production window begins.
– Delivery artefacts across the migration
Documents and operational assets your team keeps after handover
- Risk register - identified risks, mitigations and owners, maintained throughout the project.
- Test matrix - what is tested, how, and what counts as a pass.
- RPO/RTO worksheet - where relevant, recovery objectives validated against reality, not assumed.
- Cutover runbook - timed steps, verification points, responsibilities.
- Rollback plan and criteria - the conditions and the procedure, written before they are needed.
- Target architecture and sizing - documented trade-offs, resilience requirements and operating model.
- Operational handover - runbooks, monitoring setup, documentation and practical sessions with your engineers.
– Who you work with
Senior specialists, directly involved
Rollback criteria, the downtime budget and decision ownership are agreed in writing
before the production window begins.
JS
Jan Suchánek
Co-Founder & Principal Consultant
Oracle · PostgreSQL · Database migrations · Performance engineering
25+ years working with business-critical database environments
Jan specialises in database architecture, migration, performance and operational reliability. His background includes Oracle RAC, Data Guard, ASM, Exadata, PostgreSQL and cloud database environments.
LinkedIn P2D2 talk GitHub
BL
Barbora Linhartová
Co-Founder & Senior Consultant
Data integration · Data governance · Cloud and data platform transformation
Barbora works across database services, data integration, data governance and cloud transformation. She helps connect technical platform decisions with the surrounding data landscape, governance requirements and operating model.
LinkedIn Baremon blog
– Common questions
Before you get in touch
Yes. It is a complimentary 30–45 minute discussion to understand your situation and determine the appropriate next step. It does not include a formal technical assessment or written recommendations.
Yes. It is a complimentary 30–45 minute discussion to understand your situation and
determine the appropriate next step. It does not include a formal technical assessment or
written recommendations.
We discuss your current platform, the reason for the proposed change, known constraints
and the decisions you need to make. After the discussion, we recommend whether to
proceed with an assessment, a proof of concept or another appropriate next step.
Yes. It is a scoped consulting engagement with defined activities and deliverables. We
confirm the scope, timing and commercial terms after the initial review.
A focused assessment typically takes two to three weeks. Complex environments involving
multiple databases, applications or target options may require a broader scope, which we
confirm after the initial review.
No. Target selection can be part of the assessment. We compare realistic options against
workload, compatibility, operating model and long-term cost.
Yes. The assessment can be delivered as an independent engagement. Your team can then
execute the migration internally or continue with Baremon.
We assess data volume, change rate, migration tooling, validation requirements, application
dependencies and rollback constraints before recommending a cutover approach.
No production credentials are required. We usually begin with architecture, platform,
workload and operational information.
Yes. Database migration usually requires coordination across application, infrastructure,
security and operations teams.
– Start with a review
Request an initial migration review
Tell us where you are starting from. We will review your enquiry and
arrange an initial discussion.
You do not need to provide a complete specification. Please do not
include credentials or confidential production data.
We use your details to respond to and manage your enquiry. See our
privacy policy.