In the middle of 2025, the Traffic Journal, a Scopus Q2-indexed publication from Zagreb University of Croatia, approached the OJT Team with a complex OJS migration challenge, they needed more than just a standard data transfer. They required a complete OJS merge of two separate Open Journal Systems (OJS) installations into one unified platform— and it had to be done with zero downtime, ensuring that authors, reviewers, and readers experienced uninterrupted access throughout the process.
This project required meticulous coordination across multiple stages, including data mapping, cross-version compatibility checks, advanced database synchronization, and many others. Each OJS instance contained unique configurations, data structure, etc. that needed to be preserved accurately during the merge. We designed a custom migration plugin to consolidate issue data, articles, author names, keywords, abstracts, PDF files, metrics, and more while ensuring consistent metadata integrity and DOI links.
Table of Contents
The Challenge: Operating Two Separate Platforms
Traffic Journal’s editorial team had been managing two distinct OJS installations for several years. While this setup initially served their needs, it gradually created operational inefficiencies that were impacting their workflow and growth potential. Therefore, in the long term, managing two different OJS installations would risk creating various obstacles in terms of management, maintenance, indexing, and other important aspects of OJS in the future.
The primary issues included:
Duplicate administrative overhead – Every system update, user management task, and configuration change had to be performed twice, consuming valuable editorial time and increasing the risk of inconsistencies between platforms. The editorial team described their frustration: “Every time we needed to update OJS, it was like running two separate journals. Our technical person would spend an entire weekend on updates, and we’d still end up with version mismatches.”
Fragmented publication history – The journal’s complete archive was split across two systems, making it difficult for researchers to access the full scope of published work and hindering the journal’s discoverability.
Workflow complexity – Managing submissions, reviews, and publications across two separate platforms created unnecessary complexity for editors, reviewers, and authors.SEO and visibility limitations – Having content distributed across multiple domains was diluting the journal’s search engine presence and overall online visibility. Journal visibility should be centralized, but in this case become actually fragmented, causing visitor traffic to stagnate or grow slowly. You also need to know more about The Benefit of SEO for OJS
Critical Requirement: Zero Downtime Migration
The most significant constraint for this project was maintaining continuous operation throughout the migration process. As the editor-in-chief explained during our initial consultation, “Whatever we do, the journal cannot go offline. We have authors checking submission statuses, reviewers accessing manuscripts, and readers downloading articles around the clock.”
As an internationally recognized journal serving the global transportation research community, Traffic Journal could not afford any service interruption that might affect:
- Author submission processes
- Reviewer access to manuscripts
- Reader access to published content
- Editorial workflow continuity
- Indexing service requirements
This requirement immediately ruled out standard OJS migration approaches that typically involve temporary site closure or reduced functionality during the transfer process. This posed a challenge for us, but with our team’s years of experience, we found an effective way to do this without sacrificing any aspects. This allowed the process to run even without a single second of downtime.
Why Standard OJS Native XML Export-Import Tools Were Insufficient
As we all know, OJS includes built-in OJS Native XML export-import functionality designed for data migration between installations. However, for a journal of Traffic Journal’s scale and reputation, the standard OJS Native XML export-import approach presented several critical limitations:
File size and performance issues – The complete data export generated extremely large XML files due to Base64-encoded PDF attachments, creating server performance bottlenecks and extended processing times.
When the journal’s IT consultant initially explored this option, they reported back with concern: “We tried a test export and the XML file was enormous—several gigabytes. There’s no way we can process that without major downtime and server strain.”
Incomplete data coverage – The standard export process does not include several essential data types, including article categories, detailed usage metrics, and various customizations developed over years of operation.
Extended downtime requirements – Processing large export files through the standard OJS Native XML export-import mechanism would require several hours of system unavailability, violating the client’s operational requirements.
Our technical lead Dhani put it bluntly during the project planning phase: “It’s ridiculous to expect any journal to upload a 3GB file through a web browser while their live traffic continues. Even if the server could handle it, we’d be looking at 6-8 hours of processing time, completely disrupting their current operations.”
Data integrity risks – The standard OJS Native XML export-import process carries inherent risks of incomplete transfers or metadata corruption, particularly problematic for a journal maintaining strict indexing standards.
Given these limitations and the client’s Scopus-indexed status, the OJT Team determined that a custom OJS migration solution was necessary.
Solution: OJT Team’s Custom OJS Merge Plugin Development
The OJT Team’s development experts created a specialized tool—the OJS Merge Plugin—designed specifically to handle complex, zero-downtime OJS migration between OJS installations. Here is one view of the merge plugin we have developed:
Core Technical Features
Background processing architecture – The plugin operates independently of standard web requests, allowing normal journal operations to continue uninterrupted during the migration process. As our team lead Faisal explained to the client, “Think of it like renovating your house while you’re still living in it—the work happens behind the scenes without disrupting your daily routine.”
Comprehensive data coverage – Unlike standard tools, our plugin migrates all essential data types including articles, issues, categories, user accounts, usage metrics, file attachments, and historical logs.
Version compatibility handling – The system automatically adapts data structures between different OJS versions, ensuring seamless OJS merge integration regardless of source and target system versions.
Incremental transfer methodology – Data migration occurs in manageable batches to prevent server overload and maintain system responsiveness throughout the OJS migration process.
OJS Migration Execution and Results
The OJS migration process was completed within a single business day while maintaining full operational capability. Even all data transfer processes can run smoothly 100%, as you can see in one of these indicators:
The OJT Team’s systematic approach included:
- Pre-migration assessment – Comprehensive analysis of both installations to identify structural differences and optimize transfer parameters
- Background synchronization – Gradual transfer of all content and user data during low-traffic periods
- File system migration – Systematic relocation of PDF files, supplementary materials, and media assets
- Metrics database transfer – Migration of over 1.5 million usage records while preserving complete historical accuracy
- Final verification – Comprehensive validation of all migrated data to ensure complete accuracy and system stability
Quantifiable Outcomes
The journal’s editorial team was impressed with the results. As they noted in their feedback, “Our editorial workflow has been transformed. Instead of managing two separate systems, everything now happens in one place, and our complete publication history is finally unified.”
Key achievements included:
- Zero service interruption throughout the entire migration process
- Complete data preservation with 100% accuracy across all migrated elements
- Immediate workflow improvement through unified platform management
- Enhanced SEO performance via consolidated domain structure
Significant operational cost reduction through elimination of duplicate system maintenance
Technical Implementation Details
The OJT Team addressed several complex technical challenges specific to academic publishing platforms during this OJS merge:
a. Large-scale metrics migration – Successfully transferred and validated over 1.5 million individual usage records without data loss or corruption. During the metrics transfer phase, our monitoring showed the massive scale of data involved. As Dhani noted while reviewing the progress, “We’re moving 1.5 million metric records here—every download, every page view, every interaction from years of operation. This isn’t just data migration; it’s preserving the journal’s complete impact history.”
b. Cross-version compatibility – Seamlessly adapted data structures between different OJS versions while preserving all functional relationships.
c. File system integration – Maintained all existing URL structures and file relationships to prevent broken links or access issues.
d. Performance optimization – Ensured that background migration processes did not impact live system performance or user experience.
This is an illustration of the process running in the background.
And this is a summary of the processed data representation.
Current Plugin Limitations
While the OJS Merge Plugin successfully addressed Traffic Journal’s specific requirements, the current version has several limitations that potential users should consider:
Version Compatibility
- Source system requirement: Currently supports only OJS version 3.1 as the source platform
- Target system requirement: Compatible exclusively with OJS version 3.3 as the migration destination
- Version expansion: Support for additional OJS versions would require further development work
Data Scope Coverage
The current plugin implementation covers the following data types:
- Published issues and articles
- Unassigned articles and draft content
- Usage metrics and statistical data
Not currently included:
- Active submissions in review process
- User assigned in editorial workflow
- Editorial comments, note, discussion
- Activity log
- Reviewer form
- Extended metadata fields beyond core article information
- Custom editorial workflow configurations
These limitations reflect the specific scope requested by Traffic Journal. Additional features can be developed based on client requirements. We are ready to further develop this plugin if, in the future, anyone needs to migrate data with different or more complex cases. So there is nothing to worry about.
Infrastructure Requirements
- Server environment: Requires VPS (Virtual Private Server) or dedicated server hosting environment
- Hosting limitations: Cannot be implemented on shared hosting platforms or cPanel-based environments
- System access: Requires root-level server access for proper installation and operation
Why Choose OJT Team for Your OJS Migration
This case study demonstrates the OJT Team’s expertise in delivering tailored OJS migration solutions for academic publishing operations. The success of Traffic Journal’s OJS merge highlights several key principles that guide our approach to complex OJS migration projects:
Operational continuity over convenience – Prioritizing uninterrupted service delivery, even when it requires developing custom solutions rather than using standard tools.
The project’s success reinforced an important principle that Faisal emphasized to the team: “It would have been much easier to tell them to accept some downtime and use the standard tools. But that’s not what they needed. Sometimes doing the right thing means building the solution that serves the client’s actual requirements, not taking shortcuts.”
Comprehensive data preservation – Ensuring that years of editorial work, usage data, and reader relationships remain intact throughout system transitions.
Scalable technical architecture – Implementing solutions that can handle large datasets and complex requirements without compromising performance.
Long-term operational efficiency – Investing in proper migration techniques that result in genuine workflow improvements rather than temporary fixes.
Conclusion
We have successfully without any interruption for unifying a journal from a domain to another domain that has a different OJS version.
The satisfaction of the customer reflect with their testimony of our work :
The successful OJS merge of Traffic Journal’s two OJS installations demonstrates that complex academic publishing challenges can be resolved without compromising operational integrity. Through careful analysis, custom tool development, and systematic implementation, the OJT Team achieved a seamless OJS migration that enhanced rather than disrupted the journal’s operations.
Not only that, but the Traffic Journal continues to work with us to this day. Especially, they continue to use our OJS Support and Security Services, which further strengthens and guarantees the security of their data. Moreover, they are a highly reputable journal that not only requires ease of management but also values the security of their OJS data. And it has been proven that to this day, their OJS site is 1000% secure without any interruption.
For publishers considering similar OJS migration projects, this case study illustrates the importance of understanding specific requirements and developing appropriate technical solutions rather than forcing existing OJS Native XML export-import tools to handle incompatible scenarios.
The OJT Team’s investment in proper OJS migration methodology resulted in immediate operational benefits and positioned Traffic Journal for continued growth as a unified, more efficient publishing platform.
