Swiss Post: 30 ServiceNow Integrations in Hours, Not Months

Key Takeaways:

• Swiss Post integrated 30 peripheral systems into ServiceNow in hours of configuration, not months of custom development
• The solution handles 100,000+ requests daily and 100 million data entities — with zero negative impact on the ServiceNow instance
• Configuration-based integration meant no custom code on the ServiceNow side, removing ongoing maintenance burden entirely
• Initial skepticism from teams preferring the standard Table API dissolved after seeing production results — all systems moved to Squid
• Squid was installed in 90 minutes and most integrations were configured the same day, with only 2 to 3 complex systems requiring up to half a day

Switzerland's national postal service faced a challenge that will sound familiar to anyone who has led a ServiceNow implementation: modernize IT infrastructure without breaking everything that already works.

Swiss Post needed to replace 20 legacy systems that handled change management, incident tracking, configuration management, and knowledge management. These systems had been developed in-house and required extensive maintenance. ServiceNow offered a path to standardization and modernization. But approximately 30 other peripheral systems remained operational and required data from the new ServiceNow instance.

The traditional approach would have been to build custom REST APIs for each system, or adapt ServiceNow's native Table API with extensive custom code. Based on typical integration timelines, this would have meant days or weeks per system, potentially consuming months of development effort and delaying the overall project.

What actually happened was different. Swiss Post integrated all 30 peripheral systems in a compressed timeline that fundamentally changed the project economics. This is the technical story of how that integration worked, what made it possible, and what it means for organizations facing similar challenges.

The Technical Challenge

The 30 peripheral systems at Swiss Post represented the typical complexity of an enterprise IT ecosystem. These were not simple applications requesting basic data. They included:

• Security Applications: Network Access Control systems that needed current server and user configurations. IP Address Management (IPAM) platforms that tracked network resources. Firewall management tools that required service relationships and change approval status.

• Cost Allocation Systems: Internal billing platforms that needed comprehensive configuration item data. These systems allocated IT costs by department and service, requiring detailed information about every server, application, and infrastructure component. The data relationships were complex, involving machine information from Postomats and servers to Postbuses, physical room bookings and their schedules, department assignments, and service dependencies.

• Telephone Management Systems: Platforms that tracked telecommunication assets and costs, requiring configuration data and service relationships.

• DevOps Platforms: Continuous integration and deployment tools that needed change approval status, configuration details, and deployment target information.

• Monitoring and Discovery Tools: Infrastructure monitoring platforms that required current configuration data, service relationships, and incident status.

Each system had different data requirements. Some needed simple configuration item attributes. Others required complex relationships across multiple ServiceNow tables. Some systems could work with scheduled data exports. Others needed near-real-time access. The integration architecture needed to accommodate this diversity without requiring 30 different custom solutions.

Why Custom REST APIs Were Not Sustainable

The conventional approach to this challenge involves building custom REST endpoints for each peripheral system. A developer analyzes what data the system needs, identifies the relevant ServiceNow tables, writes code to query those tables, implements business logic to structure the response, and creates documentation for the integration.

For a single system, this might take a week. For systems with complex data requirements, it could take several weeks. Multiply this across 30 systems and you are looking at months of development effort, even with multiple developers working in parallel.

But the timeline is only part of the problem. Custom code requires ongoing maintenance. When ServiceNow gets updated, the code potentially needs modification. When business requirements change, someone needs to modify the code, test it, and redeploy. When the original developer leaves, knowledge transfer becomes critical. This maintenance burden accumulates over years.

Additionally, custom code introduces governance challenges. Who has access to which data? What gets logged when data is accessed? How do you ensure consistent security patterns across 30 different integrations? Each custom implementation needs its own access controls and audit capabilities.

Swiss Post evaluated this path and recognized it was not sustainable for their requirements. They needed an approach that could scale across all systems, accommodate future growth, and minimize ongoing maintenance burden.

The 90-Minute Deployment That Changed Everything

The alternative approach centered on configuration rather than custom code. Instead of writing 30 custom integrations, the team would install a single integration platform and configure it for each system's specific data requirements.

The initial deployment of this platform took approximately 90 minutes. This included installing the application into the ServiceNow instance, configuring the basic security settings, and validating the installation. At the end of those 90 minutes, the integration infrastructure was ready to start serving data.

This 90-minute deployment was not the complete integration story. Each peripheral system still needed its own configuration to define what data it required and how that data should be structured. But the fundamental difference was clear: configuration work measured in minutes to hours rather than custom development measured in days to weeks.

For straightforward data requirements, configurations took 10-30 minutes to create. A system that needed basic configuration item information or simple service relationships could be integrated quickly. More complex requirements that involved multiple table joins and sophisticated data relationships took longer, typically up to 3 hours for the most complex cases.

Importantly, a small number of systems (2-3 out of the 30) required very specific data views that took additional time to configure correctly. These were not technical challenges but business logic challenges. The peripheral systems needed data structured in particular ways that required 2-4 calendar weeks to clarify with stakeholders, define properly, and validate. The complexity was in understanding what data was actually needed and why, not in the technical implementation.

Almost all other peripheral systems were integrated with minimal effort on the ServiceNow side. The technical implementation was straightforward once the data requirements were clearly defined.

Configuration Approach: Pre-Built Patterns, Zero Custom Code

The configuration approach worked because most integration requirements follow recognizable patterns. Systems need configuration item data. They need service relationships. They need change status. They need user information. While the specific combinations vary by system, the underlying patterns are consistent.

The integration platform included more than 200 pre-built configuration patterns. These patterns addressed common data requirements across the ServiceNow data model. When a peripheral system needed data, the team could often assemble a solution from existing patterns rather than building something new.

For example, a monitoring system might need server configuration details including hostname, IP address, operating system, and associated services. This is a standard pattern that appears repeatedly across monitoring tools. Rather than writing custom code for each monitoring system, the configuration defined which specific attributes were needed and how they should be formatted in the JSON response.

When requirements did not match existing patterns, new configurations could be created. This configuration work required understanding ServiceNow's data model and the peripheral system's requirements, but it did not require writing and testing custom code. The configuration defined the data relationships and structure. The platform handled the actual data retrieval and formatting.

This approach eliminated custom code on the ServiceNow side for all integrations requiring data from ServiceNow. The peripheral systems themselves sometimes required code changes to consume the data, but that was unavoidable and depended largely on the quality of the peripheral system's architecture. The ServiceNow side remained configuration-based.

Production Results: 100,000 Requests Daily, 100 Million Entities per Day, Years of Stability

Swiss Post's integration platform went into production in summer 2025. The system now processes approximately 100,000 requests per day, handling queries from all 30 peripheral systems. The data volume is substantial: 100 million data entities managed across these integrations.

This production performance demonstrates several important characteristics. First, the configuration approach scales. The system handles high request volumes without performance degradation. Second, the architecture is reliable. Over two years of development and now half a year in production, the integration platform has operated without significant issues. Third, the operational burden is minimal.

According to Tim Schären, Solution Architect at Swiss Post, daily maintenance of the peripheral systems costs practically nothing. Once a peripheral system is configured and integrated, it functions without requiring ongoing intervention. Configuration changes can be made when needed, typically in minutes to hours depending on complexity, but the baseline operation is stable.

This operational stability is particularly significant for organizations that have experienced the maintenance burden of custom integration code. When business requirements change or ServiceNow gets updated, configuration-based integrations often need minimal or no modification. The platform itself gets maintained and updated by the vendor, not by Swiss Post's team. This dramatically reduces total cost of ownership.

Technical Architecture: How It Actually Works

The technical architecture provides structured data access through a standardized interface. Peripheral systems make HTTP requests to defined endpoints. These endpoints are configured to retrieve specific data from ServiceNow tables, apply any necessary joins or filtering, and return the results in JSON format.

The data retrieval happens through a single request. This is fundamentally different from ServiceNow's native Table API, which typically requires 8-11 sequential requests to retrieve related data across multiple tables. A system needing server details along with associated user information and network configuration would need multiple API calls with the Table API. With the configuration-based approach, one request returns all related data in a structured format.

This request efficiency matters at scale. When you are processing 100,000 requests per day, reducing each logical query from multiple API calls to a single call has significant performance and infrastructure implications. The peripheral systems benefit from simpler integration code. The ServiceNow instance experiences lower load. The network traffic decreases.

Security and access control are built into the platform rather than implemented per integration. Each peripheral system has defined data access rights based on role-based controls. All data access gets logged for audit purposes. This governance capability was not easily achievable with multiple custom integrations, but becomes standard with the configuration approach.

The Complex Use Case: Internal IT Billing

One of Swiss Post's most demanding use cases illustrates how the configuration approach handles sophisticated requirements. The organization's internal IT billing system allocates costs by department based on actual service usage. This requires comprehensive data about configuration items, service relationships, and usage patterns.

The billing system needs to know about every Postomat, server, and Postbus. It needs service relationships to understand which applications depend on which infrastructure. It needs to track these relationships over time to calculate costs accurately.

This represents probably the most complex data requirement that Swiss Post implements with the configuration platform. The relationships span multiple ServiceNow tables. The data volume is substantial. And accuracy is critical because it directly affects internal financial allocations.

Yet even this complex use case was integrated successfully using configuration rather than custom code. The configuration defines the table relationships, the data attributes needed, and how the information should be structured in the response. The platform handles the data retrieval and formatting automatically.

This use case demonstrates that configuration-based integration can handle real-world business complexity. It is not limited to simple, straightforward data exports. When the configuration can express the data relationships and business logic required, the approach scales to sophisticated requirements.

What This Means for Your Next ServiceNow Bid

The Swiss Post implementation provides several lessons for organizations planning ServiceNow integrations:

• Integration Timeline Is Predictable: When you use configuration rather than custom code, you can estimate integration effort accurately. Simple systems take minutes. Complex systems take hours. Very specific business logic requirements might take weeks to clarify with stakeholders, but the technical implementation remains fast. This predictability reduces project risk.

• Scale Does Not Require Linear Effort: Integrating 30 systems does not take 30 times as long as integrating one system. The configuration approach scales efficiently because patterns get reused. Your tenth integration benefits from configurations created for the first nine. Your thirtieth benefits from all previous work.

• Operational Burden Can Be Minimal: Swiss Post's experience shows that ongoing maintenance can be minimal when integration is configuration-based rather than code-based. This has significant implications for total cost of ownership. Over a five-year period, the difference between minimal maintenance and ongoing custom code support is substantial.

• Production Reliability Is Achievable: Processing 100,000 requests daily with 100 million data entities, operating for over two years without major issues, demonstrates that configuration-based integration can meet enterprise reliability requirements.

• The Approach Accommodates Complexity: The internal billing use case shows that sophisticated data requirements can be handled through configuration. When business logic can be expressed through data relationships and filtering, configuration works.

Technical Lessons Learned

Several technical insights emerge from Swiss Post's implementation:

• Upfront Data Modeling Matters: The most time-consuming part of integration was understanding what data each peripheral system actually needed and why. This business analysis and data modeling work happened regardless of the implementation approach. But with configuration-based integration, once the requirements were clear, implementation was fast.

• Pattern Recognition Accelerates Delivery: As the team integrated more systems, they recognized patterns in data requirements. These patterns informed new configurations that made subsequent integrations faster. This learning effect compounds over time.

• Peripheral System Quality Varies: Some peripheral systems were well-designed and could easily consume structured JSON data. Others required more significant modifications on their side. This was independent of the ServiceNow integration approach. The quality and architecture of the peripheral systems themselves was the variable factor.

• Governance Requirements Should Drive Architecture: Swiss Post needed comprehensive audit capabilities and role-based access control for compliance reasons. These requirements were easier to implement consistently with a centralized integration platform than with 30 separate custom integrations. Organizations should consider their governance requirements when choosing integration approaches.

The Broader Implication

Swiss Post's experience demonstrates that large-scale ServiceNow data integration can be accomplished without extensive custom development. The traditional assumption that 30 peripheral systems require months of custom REST API development is incorrect when configuration-based approaches are available.

This matters for project planning, budget estimation, and architectural decisions. Organizations do not need to accept months of integration development as inevitable. System integrators do not need to pad estimates conservatively because custom development is unpredictable. Technical teams do not need to commit to maintaining 30 custom integrations indefinitely.

The configuration approach offers a different path: compressed implementation timelines, predictable effort, minimal ongoing maintenance, and built-in governance capabilities. These advantages are not theoretical. They are demonstrated in production at scale.

For organizations planning ServiceNow implementations, the question is not whether large-scale integration is possible, but what approach will deliver integration most effectively. Swiss Post chose configuration over custom code and achieved integration timelines measured in hours and days rather than weeks and months. The results speak for themselves: 100,000 daily requests, 100 million data entities, 30 integrated systems, two years of stable production operation, and minimal ongoing maintenance burden.

This is what modern ServiceNow integration can look like when you choose the right architectural approach from the start.

Want to see the technical architecture? Review our technical documentation to understand how configuration-based integration works for your ServiceNow environment.