Case study
From cloud migration and database modernization to performance engineering and platform reliability — helping evolve a business-critical SaaS platform through years of change.
CLIENT : D-SIGHT / P2MAP
Enterprise SaaS
Decision Intelligence
The starting point
D-Sight's platform had evolved over several years into a complex, business-critical SaaS application.
As the product and customer requirements grew, the underlying technology platform needed to evolve with it.
The engineering challenges were not limited to application development. They spanned:
Cloud infrastructure
Moving away from the existing hosting environment while establishing a more robust AWS foundation.
Product rebranding
Transitioning the product identity from D-Sight to P2MAP while ensuring existing users and integrations continued to work correctly.
Database modernization
Moving from an aging PostgreSQL version to a newer supported version while preserving application behaviour and data integrity.
Security and resilience
Introducing encryption at rest and a stronger disaster recovery strategy.
Platform performance
Addressing performance problems across application code, database queries and infrastructure.
Operational reliability
Improving monitoring, alerting and the operational visibility required to run the platform reliably.
Rather than treating these as isolated projects, the work required understanding how application, database, infrastructure and operations interacted as one platform.
Workstream by workstream
01
The platform originally operated on Linode infrastructure.
As infrastructure requirements evolved, the application was migrated to Amazon Web Services, creating a stronger foundation for scaling, security, database management and operational control.
The migration involved more than moving application servers. It required coordinating:
Application hosting
PostgreSQL
Networking
SSL and certificates
Nginx
Application processes
Background jobs
Deployment configuration
DNS
Environment configuration
The migration was approached carefully to minimize disruption to an already-running SaaS product.
THE RESULT
The platform established an AWS-based infrastructure foundation that could support subsequent improvements in database management, disaster recovery, monitoring and operational reliability.
02
The product subsequently transitioned from D-Sight to P2MAP.
A product rebrand at the application level is more complicated than changing a logo or product name. Existing domains, application URLs, bookmarks, integrations and references can all depend on the previous identity.
The engineering work therefore included handling the technical implications of the transition, including:
Domain changes
URL redirection
Nginx configuration
SSL certificates
Application-level routing
Legacy URL handling
Preserving access to existing links
Resolving redirect and routing issues
The objective was to make the transition as transparent as possible for existing users while establishing the new P2MAP identity.
THE RESULT
The product was able to transition to its new identity while maintaining continuity across the application's web and infrastructure layers.
03
As the database platform aged, the existing PostgreSQL 11 environment needed to be upgraded. PostgreSQL 11 had already reached the end of Amazon RDS standard support, making database modernization an important infrastructure requirement.
The upgrade was not treated as a simple version change. Major PostgreSQL upgrades can introduce compatibility considerations across database features, extensions, queries and application behaviour.
The engineering work therefore involved:
Assessing database compatibility
Reviewing application dependencies
Planning the upgrade path
Preparing the RDS environment
Validating database behaviour
Testing application compatibility
Handling upgrade-related issues
Verifying application functionality after migration
The database was ultimately moved from PostgreSQL 11 to PostgreSQL 16, bringing the platform onto a substantially newer database generation.
THE RESULT
The upgrade established a newer and better-supported PostgreSQL foundation while reducing the operational and security risks associated with remaining on an obsolete major version.
04
Data security was another important requirement from the client. The database needed to provide encryption at rest, while the platform also needed a stronger disaster recovery strategy.
The solution was implemented using Amazon RDS, with the infrastructure designed around both data protection and recoverability.
The work covered areas including:
RDS configuration
Encryption at rest
Database backups
Recovery procedures
Disaster recovery planning
Database resilience
Operational validation
The objective was not simply to encrypt the database. It was to create a more complete approach to:
Protect the data
Back up the data
Recover the data
THE RESULT
The platform gained a stronger foundation for protecting sensitive application data and recovering from database or infrastructure incidents.
05
As the platform grew, performance issues appeared at multiple levels. Some problems originated in application code. Others were caused by database access patterns. Still others required investigation at the infrastructure or operational level.
Rather than addressing these issues independently, the engineering approach looked across the complete application stack.
Application-level performance
The application was analyzed for issues including:
N+1 queries
Inefficient ActiveRecord operations
Expensive database interactions
Slow application workflows
Unnecessary processing
Infrastructure-level performance
Infrastructure behaviour was also analyzed to identify bottlenecks and capacity-related issues. This included evaluating:
EC2 resources
Database performance
Background processing
Application processes
Network and infrastructure configuration
Operational monitoring
Monitoring was strengthened to make important failures visible rather than discovering them only after users experienced a problem. This included operational monitoring and alerting around areas such as:
Background jobs
Application processes
Database-related issues
Infrastructure health
Important application failures
THE GOAL
To move from reactive troubleshooting to observable operations.
What made it different
What made this engagement different was the breadth of the engineering work.
The challenges crossed multiple layers:
PRODUCT
D-Sight → P2MAP
APPLICATION
Ruby
Rails
Business Logic
DATABASE
PostgreSQL
RDS
Encryption
INFRASTRUCTURE
Linode → AWS
EC2
Nginx
SSL
RELIABILITY
Monitoring
Alerts
Background Jobs
Disaster Recovery
Each layer affected the others.
The work therefore required a platform engineering mindset, rather than treating infrastructure, application development and operations as separate disciplines.
What it was built with
Ruby
Ruby on Rails
PostgreSQL
PostgreSQL 11 → 16
Amazon RDS
AWS
EC2
Nginx
Docker
Background Jobs
SSL
DNS
Monitoring
Alerting
CI/CD
What changed
Vincreda helped evolve the platform across several critical dimensions.
Across the engagement:
Cloud
Migrated the platform from Linode to AWS.
Product
Supported the technical transition from D-Sight to P2MAP.
Database
Modernized PostgreSQL from 11 to 16.
Security
Implemented database encryption at rest.
Resilience
Established stronger database backup and disaster recovery capabilities.
Performance
Addressed bottlenecks across application code, database interactions and infrastructure.
Operations
Improved monitoring, alerting and production visibility.
The distinction that matters
The hardest engineering problems rarely belong to a single technology.
A slow application may actually be a database problem.
A database problem may be caused by application behaviour.
An availability issue may originate in infrastructure configuration.
A domain change may become an SSL and routing problem.
Vincreda helped turn that concept into a product experience where software, conversation design and AI work together.
From cloud migration to performance engineering.
From security to reliability.
From application code to infrastructure.