Offshore Development Center for Transport and Logistics IT
Transport and logistics IT has two layers that do not talk to each other as cleanly as they should. The operational layer — TMS, WMS, track and trace, customs systems — was often built in RPG, early Java, or proprietary platforms in the 1990s and 2000s. The digital layer — real-time visibility platforms, API integrations with carriers and customers, mobile driver apps — is built on modern cloud infrastructure. Both layers are production-critical. Neither can stop.
The Build Operate Transfer (BOT) model builds a delivery center that covers both. A BOT center for a logistics company can staff RPG maintenance engineers alongside Java microservices developers, with a Kafka streaming team handling real-time tracking data between the two. The client owns this team at Transfer — the institutional knowledge of the TMS configuration, the RPG business logic, and the integration architecture stays in the center.
Below: which systems a BOT center covers for transport and logistics IT, and how to structure the engagement.
Why Logistics IT Fits the BOT Model
A 3PL operating 20 warehouses and managing 10 million shipments per year cannot shut down its RPG-based WMS or legacy TMS for a re-platforming project. The legacy system runs, and the team maintaining it must be permanent and embedded. BOT provides the mechanism: build a center of RPG engineers who know the system, operate it for 2–3 years while they document and progressively modernise, then transfer them to the client as direct employees.
Track and trace, exception management, and ETD (estimated time of delivery) calculation are real-time operational systems. A streaming engineering team handling Kafka event pipelines for carrier status events, customs clearance events, and driver location updates cannot be staffed with rotating contractors who need 3 months to understand the data model.
Logistics companies add new carrier integrations, new customer portal connections, and new customs system interfaces every quarter. The integration layer — EDI, API, SFTP, web services — is never finished. A permanent embedded team that knows which integrations are fragile, which carriers have non-standard implementations, and which customers have bespoke requirements delivers more reliably than contractors who inherit integration debt they did not create.
Systems Covered in a Logistics BOT Center
| System category | Technologies | Logistics use case |
|---|---|---|
| Legacy TMS/WMS | RPG IV/RPGLE, COBOL, IBM iSeries DB2 | Freight booking, load planning, warehouse management |
| Enterprise TMS | SAP TM, Oracle TMS, custom Java TMS | Transport planning, carrier management, freight settlement |
| Warehouse management | SAP EWM, Manhattan WMS, custom WMS | Putaway, picking, packing, inventory, shipping |
| Real-time visibility | Apache Kafka, Flink, Azure Event Hubs | Carrier status events, driver location, exception management |
| Customs and compliance | Customs declaration systems, SAP GTS | Import/export, customs duty calculation, AEO compliance |
| Integration | EDI (EDIFACT, X12), REST APIs, SFTP, AS2 | Carrier connectivity, customer portals, 3PL partner networks |
| Fleet management | Telematics APIs, custom fleet management | Vehicle tracking, driver performance, fuel management |
| Analytics | Databricks, Power BI, dbt | On-time delivery, carrier performance, cost per shipment |
RPG and Legacy TMS Systems
IBM iSeries (AS/400) platforms running RPG IV and RPGLE are the backbone of a significant number of mid-to-large logistics and transport companies in Germany, the Netherlands, the UK, and North America. These systems handle freight booking, load building, carrier allocation, rate calculation, invoicing, and often warehouse management.
The RPG codebase in a mid-size logistics operator can span 1–3 million lines of code, much of it undocumented, built incrementally over 20 years. The engineers who understand it are approaching retirement age in Western Europe.
A BOT center for RPG logistics maintenance typically covers:
- RPG IV / RPGLE development and maintenance
- CL programming for job scheduling and batch operations
- DB2 for i — complex queries, performance tuning, database maintenance
- EDI interface maintenance (EDIFACT IFTMIN, IFTSTA, IFTMCS, CUSCAR)
- Report and dashboard extraction from iSeries data
- Migration planning — identifying which modules are candidates for re-platforming vs long-term maintenance
Legacy TMS modernisation via BOT
The strangler-fig pattern in logistics: the BOT center maintains the RPG TMS while simultaneously building Java microservices that replace individual functional areas. Freight booking may migrate first, then carrier rate management, then invoicing. The RPG team and the Java team share the center — domain knowledge flows between them. At Transfer, the client inherits both the engineers who know the legacy system and those who built its replacement.
SAP Transportation Management
SAP Transportation Management (SAP TM, now part of SAP S/4HANA) is the enterprise TMS of choice for large logistics companies and for the logistics functions of manufacturing, retail, and CPG companies. SAP TM covers:
- Transport demand management: freight order creation from sales orders, stock transfers, purchase orders
- Planning and optimisation: route planning, load consolidation, carrier selection
- Tendering and carrier management: spot rate requests, contract rate management
- Execution and tracking: freight order status, event management, track and trace integration
- Freight settlement: freight cost document, carrier invoice verification, charge management
Roles in a SAP TM BOT center
- SAP TM Functional Consultant: transport planning configuration, carrier management, rate tables
- SAP TM Technical Consultant: BOPF, POWL, BRF+, custom freight calculation
- ABAP Developer: enhancement implementations, interface development, custom reports
- SAP GTS Consultant: global trade services, customs declaration, embargo checking
- SAP EWM Consultant: warehouse operations connected to TM execution
Real-Time Tracking and Streaming Architecture
Real-time visibility — where is my shipment, when will it arrive, has there been an exception — is the primary competitive differentiator for logistics companies and a base expectation for their customers. The engineering behind it:
Carrier status events arrive via EDI (EDIFACT IFTSTA), carrier APIs (DHL, UPS, FedEx, DB Schenker, DSV all publish tracking APIs), and telematics feeds from vehicle tracking platforms. Apache Kafka or Azure Event Hubs collects these events, normalises them, and routes them to downstream consumers.
Apache Flink or Kafka Streams processes the event stream: deduplication, ETD calculation, exception detection (delayed, damaged, customs held), alert triggering. This is complex stateful stream processing. Engineers who build this need Kafka and stream processing expertise alongside logistics domain knowledge of what constitutes an exception and what the SLA implications are.
Customer-facing track and trace portals, internal operational dashboards, and carrier performance monitoring all consume the processed event stream in near-real-time.
A streaming engineering cohort of 4–6 engineers within a logistics BOT center covers this full stack. The minimum viable team for a production real-time visibility platform is 3 Kafka/streaming engineers plus 2 integration engineers handling carrier connectivity.
Integration: Carrier EDI and Customer APIs
Logistics companies integrate with more external parties than almost any other industry. A large 3PL might have:
- 200+ carrier EDI connections (EDIFACT IFTMIN, IFTSTA, CUSCAR, COARRI)
- 50+ customer API integrations (REST, SOAP, proprietary portals)
- 20+ 3PL partner connections (subcontractor logistics)
- 10+ customs systems (national customs portals across operating countries)
The integration layer is never finished. New carriers are onboarded. Customers change their API specifications. Customs requirements change with regulatory updates. This creates permanent, continuous integration engineering demand.
Roles in an integration-focused logistics BOT cohort:
- Integration Architect: EDI and API architecture, middleware platform governance
- EDI Developer: EDIFACT mapping, AS2/SFTP connectivity, carrier-specific implementations
- API Developer (Java/Spring Boot): REST API development, webhook implementation, OpenAPI specification
- Middleware Engineer: MuleSoft, Azure Integration Services, Boomi, IBM DataPower
- Integration Tester: end-to-end testing of carrier and customer connections
Data & Analytics for Logistics
Logistics analytics has two distinct audiences: operational managers who need daily KPI visibility, and commercial teams who need carrier cost optimisation and customer profitability analysis.
| Layer | Technologies | Logistics use case |
|---|---|---|
| Ingestion | Kafka, Fivetran, SAP extractors, custom TMS APIs | TMS data, carrier events, WMS data, telematics |
| Processing | Databricks, dbt, Snowflake | OTD calculation, cost per shipment, carrier performance |
| Consumption | Power BI, Tableau, custom dashboards | Operations KPIs, commercial reporting, customer SLAs |
| Governance | Great Expectations, Collibra | Shipment data quality, carrier rate data governance |
Key logistics KPIs requiring data engineering: On-Time Delivery (OTD), On-Time In-Full (OTIF), Cost Per Shipment (by lane, carrier, mode), Carrier Claim Rate, Dock-to-Stock time (WMS), Inventory Accuracy.
Cost Benchmarks
Indicative monthly per-head BOT rates for a transport and logistics IT center in Romania:
| Role | Romania gross salary (€/month) | BOT per-head rate (est.) |
|---|---|---|
| RPG IV Developer (senior) | €3,800–€5,500 | €5,000–€7,200 |
| SAP TM Consultant (senior) | €4,000–€6,500 | €5,200–€8,500 |
| SAP EWM Consultant (senior) | €4,000–€6,000 | €5,200–€7,800 |
| Java Developer / Spring Boot (senior) | €4,000–€6,500 | €5,200–€8,500 |
| Kafka / Streaming Engineer | €4,500–€7,000 | €5,800–€9,100 |
| EDI / Integration Developer | €3,500–€5,500 | €4,600–€7,200 |
| Data Engineer (Databricks) | €4,500–€7,000 | €5,800–€9,100 |
Build Phase for Logistics IT Centers
Logistics systems operate around the clock. The Build phase must include agreement on on-call coverage for production incidents — response time SLAs, escalation paths, on-call compensation compliant with Romanian labour law. A BOT center in Romania (UTC+2/+3) covers European business hours fully. For overnight coverage, a follow-the-sun arrangement with an Indian resource or a defined on-call roster for the Romanian team covers the gap.
New carrier EDI connections require testing with the carrier's integration team, which can take 4–8 weeks per carrier. The Build phase timeline must account for integration testing cycles with carrier partners, not just internal development timelines.
RPG engineers who join the BOT center need to understand the business logic in the system, not just the RPG syntax. The Build phase knowledge transfer must include a system documentation walk-through, business process context, known system quirks and limitations, and existing integration interfaces. Allocate 2 full weeks for this. Budget for key knowledge holders from the client's existing team to be available for Q&A during the first 90 days.
Frequently Asked Questions
Can a BOT center handle on-call support for 24/7 logistics operations?
Yes. The BOT operating agreement specifies on-call arrangements: roster structure, response time SLAs by severity level, escalation paths to client operations management, and on-call compensation in compliance with Romanian labour law. For P1 production incidents (system down, no bookings processing), typical SLAs are 30-minute response, 4-hour resolution target. Romania's UTC+2/+3 time zone means the on-call engineer during European overnight hours is working during their late evening — on-call allowances rather than full night shifts are the standard structure.
Is there RPG talent in Romania for logistics IT?
Romania has RPG talent from logistics, distribution, and manufacturing companies that run iSeries platforms. The pool is smaller than the SAP or Java market and requires active headhunting — RPG engineers with logistics domain experience are not found through standard job postings. Poland, the Czech Republic, and Ukraine also have RPG talent. For a center of 8–12 RPG engineers, a multi-country sourcing approach across Romania and Poland is more reliable than single-country sourcing.
How does a BOT center handle customs compliance engineering across multiple jurisdictions?
Logistics companies operating across multiple EU and non-EU countries require customs compliance IT across different national customs systems (ATLAS in Germany, HMRC CDS in the UK, PLATON in Poland, etc.). A BOT center covering customs IT maintains engineers who understand the regulatory requirements in the relevant jurisdictions, typically through a combination of SAP GTS specialists and custom-system developers. Regulatory changes — new customs procedures, CBAM, Import One-Stop Shop changes — are handled through the normal change management process, with the client's compliance team providing regulatory context and the center's engineers implementing the technical changes.
What is the typical team structure for a 3PL BOT center?
A typical 15-person 3PL BOT center splits across: legacy TMS/WMS (RPG or early Java) — 5 engineers; SAP TM/EWM — 4 consultants; integration/EDI — 3 engineers; data analytics — 3 engineers. This covers steady-state maintenance, carrier onboarding, customer integrations, and operational reporting without single points of failure on critical roles. As the center grows, legacy maintenance engineers may transition to modernisation work as RPG modules are progressively replaced.
How long does it take to transfer RPG system knowledge from the current team to the BOT center?
Structured knowledge transfer takes 3–6 months to reach a point where the BOT center can handle the full RPG support scope independently. The process: month 1, shadowing the incumbent team; month 2, shared support with BOT center taking primary responsibility; month 3, BOT center primary with incumbent available for escalation; month 4+, full independence. Gaps in documentation — and there are always gaps — surface during this period. The Build phase knowledge transfer program should create documentation as an output, not just deliver it verbally.