← Work
Institutional platform case · OSCE / ODIHR
Making a legacy platform sustainable.
A multi-year assignment around a business-critical meetings platform: first making the system understandable, then maintainable, then modern enough to survive — and finally transferable to a new maintenance team.
Role Consultant
Context OSCE Office for Democratic Institutions and Human Rights
Timeline Sep 2023–May 2026
Scope Assessment → documentation → procurement → modernization → handover
UnderstandInstitutionalizeModernizeHand over
00
Prologue · February 2023
The relationship started before the assignment did.
I first came to the OSCE Secretariat in Vienna to discuss event systems and digital operations. Months later, ODIHR asked me to assess a platform that had accumulated years of business logic, dependencies and operational knowledge — but very little institutional clarity around how it all fit together.
Starting questionHow do you improve a system when first you have to rediscover what the system actually knows?
2023
Year one · Understand
Make the system understandable again.
The first job was not redesign. It was reverse engineering: reconstructing workflows, data relationships, operational exceptions, roles and dependencies from a live institutional system that could not simply be switched off.
01Act I
From black box to shared knowledge
Before changing the system, I had to understand it.
When knowledge lives mostly in code, historic decisions and the heads of a few people, maintenance becomes fragile. I built a structured reference that translated the platform into something both technical and operational colleagues could reason about.
Internal artifacts · protected
The useful work is visible. The sensitive material is not.
The public case shows the type of artifacts and the decisions they enabled. Internal schemas, administration screens, participant data, security details and system configuration remain intentionally obscured.
NDA · 01Restricted
System & workflow map
Roles, states, dependencies and exception paths translated into an operational model.
NDA · 02Restricted
Data inventory
Structured reference for the data model and the relationships behind core workflows.
NDA · 03Restricted
Operational logic
What happens before, during and after a meeting — including edge cases that code alone did not explain.
2024
Year two · Institutionalize
Turn maintenance into a model the organization could own.
Once the platform was understood, the next challenge was institutional: translate technical reality into requirements, support expectations, procurement language and a maintenance model that did not depend on tacit knowledge.
Act II · Institutionalize
Procurement was part of the product architecture.
A maintainable platform needs more than good code. It needs a scope that another team can price, understand, support and be held accountable against. During the 2024 procurement cycle I helped turn platform knowledge into a clearer maintenance model and technical reference for the organization.
Translate legacy behavior and dependencies into shared language.
Separate maintenance, fixes, changes and operational support.
Clarify what a future provider needs to receive and be able to operate.
May–August 2024
The first tender concluded without a supplier being selected.
That made the continuity problem concrete: the procurement model was clearer, but the organization still needed the platform supported while a longer-term maintenance solution was found.
NDA
Procurement package / technical requirementsInternal content intentionally not reproduced
24–25 June 2024 · Hofburg, Vienna
The platform had to work where the institution worked.
Supplementary Human Dimension Meeting III
Tolerance and Non-Discrimination and Gender EqualityOfficial event page ↗
2025
Year three · Continuity
Become the continuity layer.
By 2025 the value of the work was increasingly about continuity: understanding how operational teams used the platform, diagnosing failures quickly, protecting registration and reporting flows, and keeping institutional events moving while larger modernization decisions were still ahead.
Act III · Operate under pressure
Production systems reveal what documentation never can.
Live meetings expose the long tail: data that arrived differently, photos that fail at the wrong moment, badge workflows, permissions, exports, document management and dozens of small dependencies that only become visible under real operational pressure.
PrincipleFix the immediate problem — but capture enough context that the same problem does not become institutional memory again.
Public meeting context
Supplementary Human Dimension Meeting I
Official event page ↗The role of media in conflict and humanitarian crises, reflecting on International Humanitarian Law and International Human Rights Law
04
Act IV · Prepare the transition
Eventually, continuity wasn’t enough.
The platform could be kept running, but the old environment was becoming the risk. The problem changed from “how do we support this?” to “how do we move it forward without losing the institutional memory embedded inside it?”
Inventory
Runtime, integrations, storage, scheduled jobs and other hidden dependencies.
Compatibility
Identify what breaks when a legacy codebase meets a modern PHP runtime.
Sequencing
Separate infrastructure change from functional change so issues could be isolated.
Fallback
Keep recovery options and operational continuity in view throughout the transition.
NDACompatibility matrix
Internal environment details intentionally obscured
2026
Year four · Modernize & hand over
Move the platform forward — then stop being a dependency.
The final phase combined runtime modernization, compatibility work, migration coordination, stabilization and a deliberate transfer of knowledge to the team that would maintain the system next.
Act V · Modernize
Modernizing the environment without rewriting the institution.
The platform moved from a legacy Debian 9-era / older PHP environment toward an updated server environment with PHP 8.3. The hard part was not installing a newer runtime. It was finding every place where years of assumptions surfaced as compatibility or operational failures.
LegacyOld server environmentWorking knowledge · accumulated dependencies
compatibility
+ migration
+ migration
UpdatedPHP 8.3 environmentStabilized live workflows · preserved institutional logic
Registration & reporting
Stabilize core paths first because operational teams depend on them most.
Runtime issues
Trace incompatibilities and failures introduced by the newer environment.
Documents & uploads
Validate integrations and edge cases around participant files and stored assets.
Badges & participant flows
Protect the parts of the platform that become visible immediately during live meetings.
NDA
Migration logs / runtime configuration / internal adminArchitecture and configuration details intentionally not reproduced
Act VI · May 2026
Make yourself unnecessary.
A strong handover is not a folder of files. It is the point where another team can understand what changed, why it changed, how to operate the system and where the remaining risks are — without needing the person who carried the context before them.
A later procurement process selected Noma Solutions as the long-term maintenance provider. My role at the end was not supplier evaluation; it was to get the platform and its accumulated technical and operational context into a handover-ready state.
The final phase included consolidated reporting, project history, version-control context and a technical briefing for the incoming maintenance provider in May 2026.
NDAConsolidated handover reportInternal document · not shown
NDAVersion-control historyInternal repository · not shown
Outcome
From black box to maintainable institutional asset.
The more mature outcome was the opposite: a legacy platform that was better understood, more supportable, modernized enough to continue operating, and documented well enough for responsibility to move on.
Institutional knowledge moved from tacit memory into structured documentation.
Requirements and support expectations became clearer for future providers.
The platform was stabilized through a newer runtime and server environment.
Handover reduced dependency on a single continuity holder.
External validation
Public acknowledgement. Formal reference.
Two different signals from ODIHR after nearly three years of work: a public acknowledgement from the organization itself, and a signed professional reference from the colleague responsible for the meetings programme.
01
Official ODIHR account · LinkedIn
Public acknowledgement
Official comment
“Thank you so much, Aleksandr, for your work, creativity and dedication.”Open full screenshot ↗
02
Lauren Baranowska · ODIHR
Formal reference
“He was able to bridge technical and operational requirements.”
Signed reference · 19 June 2026
Open signed reference PDF ↗Start a conversation
Working with a platform that has to survive institutional reality?
Legacy modernization, continuity, migration and governance are often the same problem seen from different sides.