If you’ve been following along our news and updates, you know that we’ve been announcing some exciting upgrades to ScholarOne Manuscripts, including the launch of ScholarOne Gateway, the addition of numerous new Universe integrations, and the development of AI-enabled editor tools. What’s missing in that list is some of the most important work of all – the behind-the-scenes, under-the-hood work by teams working to modernize ScholarOne’s codebase and architecture, all while ensuring stability for the thousands of journals using the platform day in and day out. This unseen work is what enables ScholarOne to roll out more updates, more quickly, and with more stability, while future-proofing the platform for the workflows of tomorrow.
The work behind new features
The most meaningful progress from the past year wasn't visible in a release note. It was a security review of the outside software ScholarOne is built on that didn't become an emergency.Like any modern application, ScholarOne is assembled from dozens of external software components — building blocks maintained by different teams, each on its own update schedule. Historically, falling behind on those updates meant that when a security flaw surfaced in one of them, fixing it required untangling years of postponed work all at once. The most recent review went differently. Updates that would have been blocked outright two years ago — held back by how far behind the rest of the system had drifted — went in without incident. The modernization work cleared those obstacles. Put simply, we can now keep these components current through small, routine updates, before the work piles up into another catch-up. Being proactive matters: engineering time spent on emergency fixes is time NOT spent on the platform improvements our client community needs.
That matters beyond day-to-day efficiency. The manuscripts, reviewer identities, editorial correspondence, and institutional data moving through ScholarOne workflows represent some of the most consequential content in scholarly publishing. A platform that treats security as a standing discipline — not a scramble when an incident forces it — is the baseline that content deserves. The shift from reacting to problems to watching for them ahead of time makes that baseline real.
We're steadily reviewing every place where information entered by users flows into and out of the system, making sure it's checked and displayed safely and consistently throughout the application. New features are built from a shared set of standardized building blocks, so the rules governing who can access what are enforced the same way everywhere. The pages users see in their browsers are moving onto a more modern foundation — one with stronger built-in protections that's also far easier to inspect. And dead code — the unused ghosts of features past that no longer run but still had to be reviewed every time — is being systematically identified and removed.
None of this is glamorous. But there's a practical consequence worth making explicit: engineering time is finite. Every hour spent untangling an emergency dependency fix is an hour not spent on the platform improvements our client community needs. The shift from reactive to proactive isn't just good hygiene — it's how we protect our capacity to innovate.
And all of this makes the platform more trustworthy, faster to change, and more reliable.
An added AI bonus
We didn't build toward AI readiness. We built toward the qualities that have always defined good software: clarity, simplicity, code that's straightforward to test, and consistency from one part of the system to the next. Those standards haven't changed. AI development tools happen to need the same things.Tools that help engineers write, review, and reason about code work materially better when that code is clean and well-organized. Older systems — layered with complexity, inconsistent approaches, and leftover dead code — are exactly where these tools struggle, because what they have to work from is muddled. Modern, well-structured code gives them something clear to work with.
While we didn't plan for this, it's the straightforward consequence of holding the same standards we always held. Good architectural decisions compound. AI tools are currently the most visible proof of that, but they're not the only ones.
A modern, well-structured platform is also one we can experiment on. The same foundation that makes routine maintenance predictable makes it easier to add new capabilities that use AI — and to explore where they genuinely help — without the fragility that slows that work down in older systems. We have the groundwork in place to move with the technology as it develops.
What comes next
The platform is in a different position than it was a year ago. Structurally sound architecture has no finish line, but today we're faster to change, more durable, and we no longer carry the kind of accumulated debt that turns routine maintenance into a risky undertaking.The Java platform upgrade we completed last year closed a gap of ten years in a single leap — moving the core technology ScholarOne runs on forward by a decade of releases at once. This was a major undertaking that cleared the way for everything else. The next one is already in planning: a much smaller, roughly two-year step, timed to the regular support cycle for that technology and scheduled before the backlog has a chance to build up again. That means a ScholarOne that takes on change at a predictable pace, delivers new capabilities faster, and doesn't ask publishers to hold their breath through major transitions. That's what a sustainable rhythm looks like: smaller, scheduled, and folded into normal operations rather than treated as a major event.
Every change continues to make the next one a little easier. That remains the standard we're holding ourselves to.
Be the first to hear about improvements by subscribing to our monthly email newsletter.