From legacy C# and SAS to a modern Python open-source stack

Starting position

A quantitative asset manager with 140 employees depended on data-driven investment decisions. The quality of quantitative analysis was its core competitive advantage — and precisely where the organisation was hitting its limits.

The IT landscape had grown organically over 15 years. Application Development worked in C#, the Research department relied on SAS and SQL. Between these worlds existed a language barrier: prototypes from Research could not be transferred directly into production applications — every handover required extensive translation work. Projects took too long, requirements piled up, and the pace of delivery could no longer keep up with market demands.

At the same time, the ESG regulatory wave in the financial sector was creating massive pressure. Asset managers had to integrate ESG data faster, more transparently and more traceably into their investment decisions. The existing legacy stack could not deliver this.

Proprietary reporting tools such as Crystal Reports had reached their limits: difficult to maintain, slow, and the business was entirely dependent on the IT department for every adjustment.

Challenge

The challenge was not only technical but above all organisational. Three fundamental problems had to be solved simultaneously:

Approach

The solution was a consistent unification on Python and the open-source stack for data analytics and AI. Not as a purely technical migration, but as an organisational transformation that affected every department and every level of the company.

The approach rested on four pillars:

Implementation

The training programme

44 employees were trained in four specialised cohorts:

Architecture and migration

The replacement of proprietary tools proceeded step by step. Crystal Reports was replaced by an open-source solution that not only delivered faster and better data, but enabled the business to create and customise their own report templates — without the IT department as intermediary.

Data models were normalised and standardised. The central data hub took over as the single reliable source for all applications and analyses.

A pragmatic example of the working style: when test data proved insufficient during development of the new Performance Attribution, the team quickly recognised that strict separation of development and production databases was causing more harm than good. Read-only access to the production database was perfectly sufficient for development and avoided the costly synchronisation process. All stakeholders were brought to the table, the problem was solved pragmatically — and development could immediately continue with current, complete data.

Collaboration at every level

The transformation was steered directly with the CTO and the Managing Director and founder. This direct line was critical for fast decisions and clear priorities. At the same time, personal exchange with employees at every level and in every department was a constant part of the work.

Not all team members could carry the migration. In Application Development, individual positions in the 10-person team had to be restaffed — a painful but necessary step that was communicated openly.

Results

Success factors and lessons learned

Migration always takes longer than expected. Technical migration is manageable. The human factor — habituation, relearning, acceptance — requires more time than any technical project plan anticipates. Providing patience and trust at the right moments was one of the most important tasks.

Personal credibility is non-negotiable. In a role as external lead over three years, you must convince not only technically but also build trust as a person. The willingness to communicate directly at every level — from managing director to junior developer — was decisive.

Pragmatism beats process. Questioning established separations and processes — as with read-only access to production data — not only saves time but signals to the team: we solve problems rather than manage processes.

Some changes require personnel consequences. Not all employees can or want to carry a fundamental technological transformation. Communicating this openly and acting early is fairer than a creeping overburdening.

Standardisation is the key. A shared programming language, standardised data models, unified development processes — these seemingly boring decisions are what enable the speed and flexibility an organisation needs.

What infrastructure has to do with investment outcomes

Quantitative strategies are only as good as their data foundation. Model on flawed inputs and you reliably get flawed outputs — regardless of how sophisticated the algorithms are.

The real value of this transformation was not the faster deployment cycle. It was the return to the core question: what is our actual source of judgement — and does our infrastructure live up to that standard?