Dinçer Logistics: Modernizing Data Operations on AWS

ABOUT THE CUSTOMER

Dinçer Logistics is an Istanbul-based logistics and supply chain services provider. Alongside road, rail, sea and air freight, the company offers specialist capabilities including contract warehousing, e-commerce logistics, temperature-controlled transport and dangerous goods handling. It operates roughly 500,000 square metres of warehouse space across nine facilities in six countries, serving corporate customers in chemicals, construction, automotive, FMCG, industrial products, mineral oil and food. The company describes itself as the only logistics provider in Türkiye with a distribution network dedicated to the chemicals sector.

CUSTOMER CHALLENGE

Dinçer Logistics generated operational data in five separate systems. Orders and finance sat in Microsoft Dynamics 365 ERP, customer data in Dynamics 365 CRM, transport movements in a MongoDB-based transport management system, warehouse movements in a warehouse management system spread across 44 separate company databases, and workforce data in a standalone HR database. The company’s data warehouse could reach only three of those five. A Microsoft SQL Server data warehouse running on a single server, together with around fifty SSIS packages, consolidated the ERP, transport and warehouse data. CRM and HR data stayed out of scope in practice, because adding each new source meant weeks of fresh development.

The business paid for that architecture every morning. Overnight batch jobs sometimes ran until six, so the operations team often began the day before the previous day’s numbers were ready. Large BI reports took thirty to ninety minutes to refresh, and when a heavy one ran, everything else sharing that server slowed down with it. If a column was renamed on the ERP side, the corresponding SSIS package broke quietly, and the team usually found out only when a figure looked wrong. Because SSIS packages are stored as XML, comparing two versions was close to impossible. A familiar reflex had settled in over the years: if it works, don’t touch it.

The single server was also a single point of failure. There was no meaningful disaster recovery behind it, so when that machine stopped, the company’s entire analytics stopped with it. Growth was the heavier concern. As Dinçer Logistics opened new warehouses and started operations in new countries, every new source system required three to eight weeks of SSIS development, and most of the data team’s time went into repairing pipelines that had broken overnight. The company’s commercial pace was limited by the pace of its data platform.

PARTNER SOLUTION

Kafein Teknoloji’s All-in Cloud team ran the project under the AWS Migration Acceleration Program (MAP) and delivered it end to end in roughly 11 weeks, including ingestion, integration and user acceptance testing.

The work began by profiling all five source systems. Which tables were genuinely in use, which were leftovers nobody had opened in years, which reports actually drove decisions. Once that inventory existed, the target architecture and the cost model became clear. The team then established the AWS landing zone along with the networking and security foundations. Connectivity between the company’s data centres and AWS was built on AWS Transit Gateway, Amazon VPC, Site-to-Site VPN and VPC Endpoints, so on-premises data reaches AWS without traversing the public internet.

AWS Glue sits at the centre of the new platform. PySpark-based Glue jobs pull from the ERP over OData/REST, the transport management system from MongoDB, the warehouse management system from SQL Server over JDBC, and CRM and HR from their own sources, all in parallel; shared Excel and CSV files on SharePoint were folded into the same pipeline. The raw output lands in Amazon S3 as Parquet, where Amazon Redshift Spectrum makes it queryable in place without copying it anywhere. The transformation layer runs dbt on Amazon ECS Fargate, turning the old pile of SQL stored procedures and scripts into models that can be tested and version-controlled. Results land in Amazon Redshift Serverless, which scales with the workload and needs no capacity planning. Amazon MWAA (Apache Airflow) handles scheduling and dependency management across the whole chain. When a step fails, nothing downstream of it runs and the right people hear about it. Credentials live in AWS Secrets Manager, container images in Amazon ECR, and monitoring and alerting run through Amazon CloudWatch.

End-to-end architecture. On-premises source systems connect privately to AWS over Site-to-Site VPN and AWS Transit Gateway; AWS Glue writes into the Amazon S3 data lake, Amazon MWAA orchestrates the whole chain, and dbt on Amazon ECS Fargate runs transformations in Amazon Redshift Serverless. All service access goes through VPC Endpoints, with credentials held in AWS Secrets Manager.

The design decision that shaped the outcome most was on the user side rather than the technical one. Kafein deliberately modelled the new mart layer to align with the old data mart schema. The logic of the BI reports the business had relied on for years was therefore left untouched; instead of being rebuilt, the reports were repointed at the new source, where they looked the same and ran far faster. Giving users nothing new to learn shortened the acceptance period considerably. The same exercise reviewed the report inventory and consolidated duplicates that had accumulated over the years.

Converting dozens of SSIS packages and hundreds of SQL stored procedures is the slowest and least consistent part of a project like this. Every engineer writes to their own habits, and what comes out the other side is hundreds of pieces of uneven quality. For this step Kafein built a template-based, automation-supported conversion pipeline with standards defined up front for each domain. Every conversion followed the same pattern: SSIS to Glue, SQL Server to Redshift, stored procedures to dbt models, SQL Server Agent jobs to Airflow DAGs. The lasting benefit was ownership. Because the code has the same shape regardless of who wrote it, the Dinçer Logistics team can extend and maintain the platform themselves, without depending on the partner.

The cut-over ran in stages. The new platform ran alongside the old environment for weeks; for each domain the old and new figures were compared, differences were resolved, and only then was that domain switched over. The cut-over was planned around daily logistics operations and delivered without disrupting them. Afterwards Kafein provided hypercare support, cost monitoring and optimisation, along with knowledge transfer and training for the customer’s team. The same period laid the groundwork for the platform to grow: a reference model based on AWS Control Tower was defined for managing additional AWS accounts, and because demand, inventory and warehouse data now sits in Amazon S3 and Amazon Redshift, AWS Supply Chain Analytics was added to the roadmap.

“The data warehouse migration went far faster and more smoothly than we expected. Nothing changed on the user side; teams opened the same reports and saw the same numbers, only much faster. The real difference came afterwards: with accurate, current data in one place, we were able to put our agentic AI services into service in a short time.”

Dr. Selman Şişman · Head of R&D, Dinçer Logistics / Dinçer Teknoloji

RESULTS AND BENEFITS

Daily data preparation dropped from four to six hours to 45–90 minutes, a reduction of roughly 75 percent, and the operations team now starts the day with yesterday’s numbers already complete. Large BI reports that took thirty to ninety minutes to refresh now take a few minutes, and that speed-up came without touching report logic; because the mart layer was designed to align with the old schema, the only thing that changed for users was the wait.

The cost picture is similar. Counting licensing, infrastructure and people together, total cost of ownership fell by roughly 51 percent. That comparison holds scope constant, which understates the change: the new platform carries two additional source systems, far more data and full automation. Adjusted for the additional servers and licences the old architecture would have needed to reach the same capacity, the saving is closer to 75 percent. The migration investment paid for itself in under a year. The DBA and DevOps resource needed to keep the platform running went from 0.75 FTE to 0.3 FTE, and the time freed up went into building new analytics.

The result that matters most for how the company grows is in speed and resilience. Onboarding a new source system went from three to eight weeks down to two to five days. Recovery time after a schema change fell from four to eight hours to one or two, and those fixes now happen through version control instead of by hand in production. The single point of failure is gone; the platform now runs on the 99.9 percent service commitments of Amazon MWAA and Amazon Redshift Serverless, with backups managed by AWS. Dynamic connection resolution means a new warehouse or a new country operation can be added without redesigning any pipeline. Dinçer Logistics no longer sets the pace of its growth by what its data platform can absorb.

FROM A MODERN DATA PLATFORM TO AI IN PRODUCTION

The return on a data lakehouse is not limited to faster reports; the real difference shows up in what becomes possible afterwards. Once ERP, CRM, transport, warehouse and HR data sat in one governed layer across Amazon S3 and Amazon Redshift, the most familiar obstacle to AI work disappeared with it: scattered, unowned data of uncertain freshness.

Development on the AI side picked up noticeably once the platform was live. Sitting directly on top of the data layer, within the same AWS environment, agentic AI solutions were built on Amazon Bedrock and Amazon SageMaker and taken into production. Those agents reach current operational data in the lakehouse directly, so when a user asks a question in natural language the answer comes from the data itself rather than from a pre-built report.

The platform is what makes that possible. The data already lives in AWS, access governance is defined, freshness is guaranteed by the pipeline and the query layer is serverless, so a new AI scenario needs no separate data path, no copying and no second security model. The modernisation project gave Dinçer Logistics a foundation, and the company keeps building on it.

CORE AWS SERVICES USED

• AWS Migration Acceleration Program (MAP) — Assess, Mobilize, Migrate & Modernize
• AWS Glue (PySpark) — parallel ingestion from ERP, CRM, TMS, WMS and HR sources
• Amazon S3 — raw data lake in Parquet format
• Amazon Redshift Serverless and Redshift Spectrum — data warehouse and in-place querying over S3
• Amazon ECS Fargate — dbt-based transformation layer
• Amazon Bedrock, Amazon SageMaker — agentic AI solutions running in production on lakehouse data
• Amazon MWAA (Apache Airflow) — orchestration and dependency management
• AWS Transit Gateway, Amazon VPC, Site-to-Site VPN, VPC Endpoints — hybrid connectivity
• AWS Secrets Manager, Amazon ECR, Amazon CloudWatch — credential management, image registry, observability

The entire platform runs in production in AWS Europe (Frankfurt) — eu-central-1. AWS Control Tower and AWS Supply Chain Analytics are not part of the initial migration scope; they are planned next steps on Dinçer Logistics’ roadmap.