From Legacy to Live: How Webskyne Helped FinEdge Migrate a 15-Year-Old ERP to a Real-Time Dashboard Platform in 120 Days

Overview

In 2025, FinEdge Corporation—a regional financial services provider managing $2.1 billion in assets under administration—faced a data infrastructure crisis. Their Enterprise Resource Planning system, first deployed in 2008, had become a patchwork of nightly batch exports, manual Excel reconciliations, and three separate reporting tools that rarely agreed on the same numbers. Department heads spent Fridays waiting for reports. The CFO’s office often received corrected figures on Monday, eight hours after the original deadline.

FinEdge had grown from a single-line insurance provider into a multi-product financial services firm through three acquisitions between 2014 and 2019. Each acquisition brought legacy systems that were never fully integrated. By 2025, the cost of maintaining this patchwork—in both direct licensing fees and indirect labor—had become a board-level concern. The CIO commissioned an independent architecture review, which concluded that replacing the batch-first reporting layer would unlock more value than any single frontend modernization effort.

Webskyne was brought in to design and implement a modern data platform that could serve accurate, real-time financial metrics to every stakeholder without disrupting ongoing compliance obligations. The project ran from January through April 2026 and delivered a production-ready solution in 120 days, well ahead of the original six-month timeline. The engagement model included a two-week paid discovery phase, followed by a fixed-scope implementation contract with milestone-based payments tied to measurable deliverables.

What made this project unusual was the combination of technical complexity and organizational sensitivity. Financial services firms operate under strict regulatory scrutiny, and any data platform change triggers audit reviews from state insurance departments and federal prudential regulators. Every design decision had to be documented, tested, and signed off before deployment. Webskyne embedded a regulatory compliance lead into the project team from day one, which eliminated the typical back-and-forth that delays many enterprise data projects.

The Challenge

FinEdge’s technology environment was typical of firms that had grown through acquisition. They operated three core line-of-business systems: a claims processing engine running on IBM z/OS, a policy administration system hosted on Oracle Database 11g, and an investment accounting platform built on SQL Server 2014. Each system emitted data in its own format—fixed-width flat files, XML streams, and database snapshots—and each had its own refresh cadence. The claims engine updated nightly, the policy system refreshed every four hours, and the investment platform ran weekly batch jobs that sometimes stretched into days during quarter-end closes.

Fragmenting this environment further was a thicket of departmental workarounds. The underwriting team had built an Access database that pulled exported CSV files from the policy system and added manually entered market data to produce pricing models. The claims department used a shared network drive full of Excel workbooks with VBA macros that recalculated reserves on demand, but only within the limits of the user’s desktop memory. The compliance team maintained a parallel set of SharePoint lists where they hand-entered figures for regulatory filings, a process that introduced transcription errors on a monthly basis.

The immediate business pain was decision latency. Underwriters needed current exposure figures to price new policies accurately. Claims adjusters needed to verify coverage limits in real time. The compliance team needed audit trails that reconciled across all three systems. None of these needs could be met by the existing batch architecture.

During discovery, we also uncovered a less visible but equally urgent problem: data sovereignty. Because no single system owned the policy record, FinEdge could not definitively answer questions like “What is our total exposure in Florida commercial property?” without running three separate queries and manually reconciling the results. When discrepancies appeared—and they appeared monthly—weeks of investigation followed. The business had learned to tolerate delayed decisions as the cost of doing business, but the cost had risen to an estimated $1.4 million annually in opportunity losses and compliance penalties.

There was also a cultural resistance to change. Several power users had built personal Excel macros and Access databases that effectively replaced missing system functionality. Any new platform had to preserve the mental models these users had developed, even as it replaced the underlying data flows.

Project Goals

We defined three primary goals at the kickoff workshop. First, reduce reporting latency from end-of-day to real-time or near-real-time for all financial metrics, with a hard ceiling of five minutes. Second, unify the data model so that every stakeholder—underwriting, claims, compliance, executive leadership—saw the same number for the same concept, with a single source of truth. Third, ensure the solution could be operated by FinEdge’s existing IT team with minimal specialist dependencies after handoff.

Secondary goals included preserving all existing audit trails, maintaining SOC 2 Type II compliance posture, and delivering a user interface that required no more than two hours of training for any power user. We also set a non-functional target: 99.9 percent availability during business hours, with a recovery point objective of one hour and a recovery time objective of four hours for the reporting layer.

Our Approach

Webskyne’s delivery model began with a two-week discovery phase focused on data lineage mapping. We interviewed twenty-three stakeholders across five departments and catalogued every data source, transformation step, and downstream report. The output was a directed graph of 147 distinct data flows, which revealed that 22 percent of all reported figures were derived from calculations performed in Excel rather than in any system of record.

We then proposed a canonical data model built around four core entities: Policy, Claim, Transaction, and Counterparty. Every upstream system would be mapped to this model through a consistent ingestion layer, eliminating the need for downstream systems to understand source-specific formats. This approach aligned with the industry-standard data mesh principles but was adapted for FinEdge’s governance requirements, which demanded centralized oversight rather than federated domain ownership.

The architecture decision turned on whether to build a traditional data warehouse or adopt a streaming-first design. Given the five-minute latency requirement and the need for real-time exposure calculations, we selected a lambda architecture: a hot path using Apache Kafka streams for sub-minute updates, and a cold path using dbt transformations on a cloud data warehouse for historical accuracy and compliance reporting. The cold path used Snowflake as the persistence layer, chosen for its native semi-structured data support and for its separation of compute and storage, which allowed FinEdge’s finance team to run historical queries without impacting real-time ingestion workloads.

We also spent significant time designing the API layer. Rather than exposing raw database tables, we built a GraphQL gateway on AWS AppSync that enforced row-level security based on the caller’s role. This meant that an underwriter in the commercial property division could only see policies within her book of business, while an executive could see aggregate figures across all lines of business. The security model mirrored FinEdge’s existing organizational structure, reducing the learning curve and eliminating the need for a complex new permissions framework.

Implementation

Week three through week eight focused on infrastructure and ingestion. We provisioned a Kafka cluster on AWS MSK, configured change-data-capture connectors from Oracle and SQL Server using Debezium, and built a file-ingestion microservice for the IBM mainframe flat files. The mainframe connector was the most complex; the system emitted fixed-width records with embedded control characters, and we had to write a custom parser that could handle seven different record types while preserving confirm-before-commit semantics required by FinEdge’s internal controls.

During weeks nine through fourteen, we built the canonical model and the hot-path streaming jobs. We used Python with Pydantic for schema validation at the ingestion boundary, ensuring that every record conformed to the target model before it could enter the Kafka topics. The transformation jobs, built with ksqlDB, materialized three aggregated views: policy exposure, claim reserve, and net asset value. These views were exposed via a GraphQL API developed on AWS AppSync, allowing frontend developers to query exactly the data they needed without over-fetching.

The user interface, built with Next.js and Tailwind CSS, went through three major design iterations. The first prototype replicated the legacy Excel layout, which users rejected because it felt dated. The second design adopted a modern card-based dashboard, which users found too abstract. The final version balanced familiarity and modernity: it retained the grid layout power users recognized, but layered interactive charts on top and added real-time status indicators that changed color as data freshness degraded. This iterative process, conducted through weekly usability reviews with a twelve-user beta group, was critical to adoption.

Results

The platform went live on April 14, 2026, after two weeks of parallel running with the legacy system. During parallel run, we compared every metric computed by the new system against the legacy batch outputs. Of the 147 data flows we identified, 139 matched exactly on day one; the remaining eight discrepancies were traced to timing differences in how the mainframe batch closed its reporting period. We adjusted the streaming job windowing and achieved full parity by day twelve.

Post-launch feedback from underwriters was immediate. Where they previously received exposure updates at 6:00 PM, they could now see new policy impact within 90 seconds of policy issuance. Claims adjusters no longer needed to call the back office to verify coverage limits. The compliance team, initially skeptical, reported that the automated audit trail—derived from the Kafka log offsets and the dbt run history—reduced their month-end reconciliation work from five days to eight hours. They also noted that the audit trail was more complete than their previous manual process, because every transformation step was version-controlled and timestamped.

One unexpected benefit emerged in the investment accounting division. Because the data warehouse stored historical snapches at fifteen-minute intervals, the portfolio managers discovered they could replay market movements and stress-test portfolio allocations in ways that had been impossible with weekly batch data. They began running scenario analyses monthly instead of quarterly, which improved their risk-adjusted returns by an estimated 0.8 percent over the first six months.

Metrics

Quantitative results were measured over a 30-day stabilization period following launch. Reporting latency dropped from a median of 18 hours and 22 minutes to 87 seconds, representing a 747x improvement. Data discrepancy incidents between departments fell from an average of 12 per month to zero over the same period. Users reported a 68 percent reduction in time spent assembling reports, and 94 percent of beta testers said they would not want to return to the old system. Infrastructure costs decreased by 35 percent compared to the combination of legacy licenses, manual labor hours, and third-party reporting tools they replaced.

System performance met the non-functional targets: the GraphQL API maintained a p95 latency of 180 milliseconds during peak load, the Kafka cluster processed 3,200 messages per second without backpressure, and data freshness degraded gracefully during one unplanned AWS outage by falling back to the last warehouse snapshot within the four-hour RTO window.

Lessons Learned

The first lesson was about change management. The Excel macros and Access databases that power users had built were not obstacles; they were evidence of unmet need. If we had replaced them without understanding the questions users were trying to answer, we would have built a technically correct system that nobody trusted. Our weekly usability reviews, conducted with actual report layouts and real data from a production-masked environment, were as important to success as the Kafka architecture.

The second lesson concerned the mainframe integration. We underestimated the effort required to parse fixed-width records with embedded control characters. The three weeks we allocated turned into five, and the custom parser became a critical dependency. In hindsight, we should have engaged a specialist with IBM z/OS background earlier rather than treating the mainframe as just another file source. That delay tightened our buffer for user acceptance testing, and we ultimately had to negotiate one week of schedule contingency with the client. We now buffer mainframe integration projects at 150 percent of initial estimates until a detailed record specification review has been completed.

The third lesson was about observability. The lambda architecture gave us resilience, but it also gave us two sets of metrics to monitor, two definitions of freshness, and two potential failure modes. Building a unified observability layer from day one—rather than retrofitting it at the end—would have reduced our stabilization period by at least a week. We now include observability engineering as a budgeted line item in every data platform engagement, with dedicated dashboards for hot-path throughput, cold-path freshness, and reconciliation failure rates.

The fourth lesson was about governance. FinEdge’s compliance team required a formal data dictionary, field-level lineage documentation, and sign-off on every transformation rule. Integrating this documentation into our agile sprints felt burdensome at first, but it paid dividends during the SOC 2 Type II audit that followed seven months after launch. Because the documentation was current and versioned, the audit passed with no material findings and only one minor observation—a faster outcome than FinEdge had achieved with any previous technology initiative. We now propose a lightweight governance wrapper as a standard part of every engagement from the proposal phase, rather than treating it as an afterthought.

Finally, the project reinforced that data migrations are human migrations. The real work was not moving bytes; it was moving trust, habits, and institutional knowledge. The metrics validate the technical approach, but the user interviews validate the methodology. Technology is the enabler; the outcome is a team that can make better decisions, faster. The most memorable feedback came from a senior underwriter who, after using the new system for two weeks, said it was the first time in her eighteen-year career that she felt her data was actually on her side. Moments like that are why we build systems.