Two Platforms, One Plan: a Modernization Path That Didn’t Stop the Business
Growth arrived before the platform was ready for it
Our client builds physician scheduling software used by hospitals in Canada and by clients in Australia, the Middle East, Europe, and the US. Its schedules cover credential eligibility, labour-safety rules, fairness and departmental policy — the kind of work that gets harder, not easier, as an organization grows.
The business hit an inflection point: new departments, new markets, rising competitive pressure, and enterprise deals appearing on the table. The technology underneath had been built for a smaller, earlier-stage company. They didn’t come to us asking to build feature X. They asked for something harder — clarity on platform direction, less delivery and operational risk, and a foundation that could carry enterprise growth without breaking what already worked for existing customers.
Platform users across hospital departments and multi-site systems
Shifts assigned every month through the platform
Of assigned shifts match a provider’s stated preference (average since 2020)
Modernising while
stuck between two platforms
Two platforms, one revenue stream
The original system of record carried nearly all customers and end-to-end workflows. A newer replacement platform was roughly 20–30% complete, used by two customers as a preference-entry tool, and still dependent on the legacy system for real scheduling operations.
Releases were fragile and manual
No standard CI/CD pipeline, deployments dependent on a custom build server with manual approval steps, and no automated tests in the release flow. Shipping a change was riskier than it needed to be, and confidence in releases was low.
Architecture made safe change harder
Business logic, authorisation and presentation were intertwined, with duplicated authorisation logic, multiple sources of truth, tight coupling between the server-rendered web layer and backend behaviour, and a parallel Node.js API alongside the original backend.
Mobile was the top complaint source
Physicians live in the mobile app, but it lacked parity with the web experience and had seen little investment for years following an acquisition. That drove recurring client complaints and constant support load.
Failures could reach customers first
Logging, metrics and alerting were limited or inconsistently configured. There were no runbooks and no documented incident response, so resolution depended on who happened to know the system best.
Enterprise limits were already surfacing
As larger clients onboarded, permissions and user management strained at scale, and operational complexity grew. Knowledge sat with individuals — a single-point-of-failure risk in a small team spread across too many technologies.
We applied our 4D approach
One platform, one backend,
one direction — reached in steps
Modernization in stages, not a big-bang rewrite
The business has to run smoothly while it changes, so the platform evolves in production. Improvements land sooner instead of at the end of a long rewrite, each change is validated gradually, and the risk of a major outage during transformation falls. It also makes the transition manageable in practice, because new and legacy components can run side by side.
One unified backend for web and mobile
Core business logic moves into a single backend API serving both the web and mobile apps. That gives one source of truth for scheduling logic, fewer duplicated features across systems, and easier maintenance with faster product updates. As the unified backend grows, legacy components retire step by step — including migrating mobile off its dedicated backend and folding remaining parallel functionality into the main platform.
A modern React web experience, delivered gradually
New pages are added incrementally, each migrated flow connects to the new secure API layer, and legacy pages are removed only once the replacement is proven stable. Users see improvements inside the modernization timeline rather than after it, and there is no all-at-once UI switch to absorb — a future-ready product with operations kept stable.
Security built for enterprise buyers
Enterprise customers bring security requirements, so the design introduces modern token-based authentication (JWT), a structured role-based permissions model (RBAC), secure secrets management with AWS Secrets Manager, and encryption at rest for relational data via AWS RDS. For non-technical stakeholders the shift is simple: access becomes easier to manage and safer to enforce, because permissions are defined as clear roles — admin, scheduler, physician, viewer — and applied consistently everywhere.
Cloud architecture designed for scaling
The target architecture is built for reliability and growth on AWS: container-based hosting on ECS Fargate, stable routing and delivery for web and APIs through S3/CloudFront with DNS routing and load balancing, isolated dev/stage/prod environments for cleaner governance, and infrastructure as code in Terraform to reduce drift. The point is a foundation that supports enterprise growth without operational complexity rising at the same rate.
A delivery process that makes change safe
Fragile manual releases were addressed directly: a standard CI/CD pipeline replacing the custom build server and manual approval steps, automated tests in the release flow, and consistent logging, metrics and alerting so failures are detected before customers report them. Runbooks and documented incident response turn resolution from tribal knowledge into a repeatable procedure.
Most reliability problems aren’t in the product
Eight weeks turned
an open question into a fundable plan
8-week audit
A full independent audit of the legacy product foundation — platforms, architecture, operations and delivery process — completed in eight weeks.
3 executive-ready documents
Needs assessment, options analysis and solution design. Together they replaced internal debate with one agreed plan.
3 paths, 9 criteria
Three strategic platform paths evaluated against nine explicit criteria — including business continuity risk, time to value and scalability readiness.
1 prioritized risk register
Every technical constraint linked to its business impact and to the expansion it was blocking, ranked by urgency rather than listed flat.
AWS Well-Architected review
Cloud-level reliability, cost and operational gaps surfaced alongside application-level ones — one view of risk instead of two.
No forced migration
A phased roadmap with milestones and sequencing, so existing revenue workflows stay stable while complexity comes down. No big-bang cutover required.
Not sure whether
to modernize or rebuild?
a ranked risk register, and a costed roadmap you can take to your board — before
committing engineering budget to either path.
Physician scheduling software modernization: FAQ
What is a legacy software audit?
A legacy software audit is a structured review of an existing software platform that documents how it works today and what it will cost to change. For this healthcare IT client, Euristiq assessed four areas over eight weeks: the codebase and technical debt, architecture redesign options, a platform modernization roadmap, and the infrastructure and deployment setup. The output was not a list of technical complaints — it was a ranked gap analysis connecting each constraint to business impact, so leadership could see which issues threatened growth, reliability, customer experience, or delivery speed.
How do you consolidate two overlapping software platforms?
Start by deciding which platform the business actually runs on, then converge the rest onto it — do not maintain both indefinitely. Our client operated a legacy system of record used by nearly all customers alongside a newer replacement platform that was roughly 20–30% complete and used by two. Euristiq recommended moving core business logic into a single backend API serving both web and mobile, creating one source of truth for scheduling logic. Legacy components are then retired step by step, rather than switched off in a single risky cutover.
Should you modernize a legacy platform in stages or rewrite it?
In stages, in almost every case where the platform is already generating revenue. A full rewrite stops visible improvement for months and concentrates all the risk at a single cutover date. Euristiq recommended phased modernization for this client: introduce improvements incrementally, validate each one in production, and only then decommission the older component. New and legacy components run side by side during the transition. For the business, improvements arrive sooner, changes are validated gradually, and the risk of a major outage during transformation drops sharply.
What does an AWS Well-Architected review cover?
An AWS Well-Architected review evaluates a cloud workload against six pillars — operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability — and produces a prioritized list of risks. It matters because many reliability and cost problems are not caused by the product itself but by how it is hosted, monitored, and maintained. For this client, Euristiq ran the review inside the audit and surfaced cloud-level gaps alongside application-level ones, giving leadership one view of operational risk instead of two disconnected assessments.
How long does a legacy software audit take?
Eight weeks, for a platform of this size. Euristiq delivered this audit with a senior cross-functional team — a business analyst, a solutions architect, an AI solutions architect, and a project manager — working in parallel across the codebase, architecture, infrastructure, and delivery process. The engagement produced three executive-ready documents: a needs assessment describing the current state, an options analysis comparing three strategic platform paths against nine decision criteria, and a solution design defining the target architecture and phased roadmap.
Recent cases
Powering a Vendor Management System Trusted by 400+ Brands
A Legacy Student Information System Modernization Roadmap for 55,000+ Students
