Give every system one reliable source of truth.
We design, organize, migrate, and connect the data behind your business, so customer records, workflows, integrations, and reporting are built on information your team can actually rely on.
The real problem
Bad data makes good software look broken.
When software feels broken, the interface takes the blame, because the interface is where the mess becomes visible. Underneath, the cause is usually the data. These are the failures we find most often, and none of them can be fixed with a new subscription.
The same customer, five times · illustrative
Website form
Jordan Rivera
jrivera@example.comNew lead
CRM
J. Rivera
(555) 014-2203Active
Invoicing
Rivera, Jordan
Balance dueClosed
Spreadsheet
jordan rivera
pasted in March?
Project tool
Rivera install
no customer linkIn progress
No shared identifier. Every one of these is somebody's source of truth.
- 01
Duplicate customers
The same person exists under several records, so conversations, jobs, and reporting fragment across them.
- 02
Conflicting fields
One system says the project is active. Another says it closed last month. Both are being used to make decisions.
- 03
Missing relationships
The customer exists. The project exists. The invoice exists. No system can reliably say they belong together.
- 04
Manual reconciliation
Someone exports spreadsheets and compares them line by line, because no authoritative source was ever established.
Source of truth
“One source of truth” doesn't mean one application has to do everything.
A business can keep running specialized tools. The question is not how many systems you have. It is which system gets to be right about each kind of information, and how the others find out.
Customer identity
Primary customer record
Owns who the customer is: identity, contact details, history
- CRM
- Portal
- Projects
- Reporting
Financial truth
Accounting system
Owns the money: invoices, balances, payments
- Operational reporting
- Project views
Marketing source
Lead acquisition record
Owns the origin: the campaign or channel that produced the lead
- CRM
- Pipeline
- Attribution reporting
The boxed system is where each kind of record becomes authoritative. The systems below read from it, and none of them get to quietly redefine it.
What we do
What we design, clean, connect, and migrate
Every CRM sits on a database. The question is whether that structure was designed around your business or the vendor's template. This page is about the bottom half of the stack, the part a polished interface cannot fix. Which of these areas your project includes is defined in scope, and working that out is the first conversation.
Interface
Screens, pipelines, forms, buttons. What the team touches.
Business logic
What a stage change triggers. What counts as won.
Data model
Records, relationships, identifiers, rules.
Database & storage
Where it physically lives, and how it is backed up.
- 01
Database & schema design
Records, fields, relationships, constraints, and identifiers, designed around what the applications above them need to do.
- 02
Data cleanup
Duplicate, malformed, incomplete, outdated, and conflicting records identified before they get carried into a new system. Some of it scripts can fix. Some of it needs a business decision, and we flag which is which.
- 03
Migration
Required records moved from existing platforms, spreadsheets, exports, or legacy systems through a defined, testable process.
- 04
Integration & synchronization
Rules for how connected systems read and update shared information, without creating duplicate records or updates that chase each other in circles.
- 05
Reporting structures
Data organized so the metrics that matter can be calculated from defined fields and relationships, instead of reconciled by hand.
- 06
Backup & recoverability
Where in scope, backup and recovery procedures matched to the system and the infrastructure it runs on.
- 07
Documentation
The important entities, relationships, ownership rules, and migration decisions written down, so the system is understandable after we leave.
The data model
The relationships matter as much as the records.
A simplified model for an example services business. The point is not these specific fields. It is that a customer exists once, as a record other records connect to, instead of as text retyped into ten places. The highlighted fields are the relationships.
Company
The business you work with
- Name
- Phone
- Billing address
Contact
A person at that company
- Name
- Companylinks to Company
Opportunity
A deal being worked
- Stage
- Sourcefrom marketing
- Contactlinks to Contact
Project
The work being delivered
- Status
- Schedule
- Opportunitylinks to Opportunity
Illustrative model for an example business, not a template
When the relationships are explicit, “show me everything about this customer” stops being a research project.
When customer identity is consistent
everyone sees the same customer history, in every system.
When records are related correctly
projects, documents, and activity connect without a human matching them.
When status definitions are consistent
automations know when to run, and when not to.
When sources are preserved
marketing spend can be traced to the outcomes it produced.
And when the applications themselves no longer fit the operation, the same schema work becomes the first phase of a system built around it.
Migration
Moving the data should be engineered, not improvised.
Replacing a system raises a fair fear: losing the history the business runs on. So the move is a defined process with checkpoints, not an export the night before cutover.
01
Inventory
Find where the records that matter actually live
02
Map
Old fields and relationships get a defined destination
03
Clean
Duplicates and conflicts surface before the move, not after
04
Test
Sample migrations run first, counts and relationships checked
05
Migrate
The approved data moves through the planned process
06
Verify
Records, relationships, and workflows checked on the other side
Planned deliberately, where the situation calls for it
- Cutover timing
- Active vs historical records
- Rollback planning
- Read-only archival where it fits
- Migration logs
Not every historical record needs to move. Sometimes read-only access to an archive is the better decision than dragging fifteen years of exports into a new schema. That is a scoping call, made deliberately.
Ownership & control
Control, portability, reporting, and recovery
The practical version of data ownership is quiet: you know where your records live, who can reach them, what a report is calculated from, and what leaving would actually take.
Portability
Documented structures and standard export paths, so your information is not trapped in an opaque format.
Access
Who and what can read or change data is defined by responsibility, not left at the defaults.
Documentation
Enough architectural context that another qualified team could understand the core structure.
Backups
Where applicable, how backups are created, retained, monitored, and restored is defined, not assumed.
Infrastructure
Where the engagement includes custom infrastructure, hosting and database architecture are deliberate decisions, not implementation afterthoughts.
Reporting
Numbers calculated from defined fields and relationships, so a dashboard is something you can defend, not decorate.
Custom systems still run on cloud providers, managed database services, and third-party APIs. Control does not mean owning physical servers, and ownership does not mean no third party is ever involved. It means clear access, workable exports, documented architecture, and no more lock-in than the job requires.
Deliverables
What you leave with
Scope varies by engagement, and not every engagement includes every item. These are the kinds of things you end up holding.
01A documented data map
A clear view of where important information lives and which system is responsible for it.
02A defined schema
Records and relationships designed around the business requirements, not a vendor template.
03Cleaned and mapped data
Existing information prepared for the agreed destination, where cleanup or migration is in scope.
04A tested migration
Required data moved and verified against an agreed migration plan.
05Defined synchronization rules
Clear behavior for how connected systems exchange and update shared information.
06A reporting-ready structure
Data organized so the agreed business reporting can be built on defined relationships and fields.
07Documentation
Enough context for the architecture to be maintained and extended responsibly.
Let's find where your systems stop agreeing.
Show us where customer, sales, project, and reporting data lives today. We'll map the systems, identify where records conflict or duplicate, and work out what should become authoritative.
Prefer email? Contact@passerelleint.com