Case Study: Migrating the CarHome Platform from .NET Framework to .NET Core with Docker Containerization

This report details the background, personnel effort, migration process, performance gains, operational experience, and lessons learned from moving a high‑traffic automotive content platform from Windows‑only .NET Framework to cross‑platform .NET Core and Docker, highlighting seamless upgrade, elasticity, and tooling improvements.

HomeTech
HomeTech
HomeTech
Case Study: Migrating the CarHome Platform from .NET Framework to .NET Core with Docker Containerization

Background

CarHome is a PGC platform that aggregates most automotive experts and opinion leaders online, delivering tens of millions of page views daily. Its backend, built with .NET 4.5, handles hundreds of millions of daily API calls. Because it runs only on Windows, scalability and migration flexibility are limited, prompting a move to Linux with container support.

Re‑writing the system in Java would require massive effort, and a front‑end‑back‑end split with Node.js would burden developers. Upgrading the existing codebase to .NET Core offers minimal syntax changes, cross‑platform capability, Docker‑based elastic scaling, and documented performance improvements, making it the chosen solution.

Personnel Investment

Period

Days

People

Person‑days

Feb 21‑Feb 27

5

1

5

Apr 1‑May 13

27

0.5

13.5

May 14‑May 24

9

1.5

13.5

May 27‑Jun 6

9

2.5

22.5

Total

54.5

Early stages involved limited effort due to learning curves; later phases intensified to accelerate the migration.

Upgrade Effects

1. Performance Improvement

Since the gray rollout on May 25, the 99th‑percentile response time dropped from ~100 ms to consistently below 45 ms.

2. Seamless Upgrade

Web, API, and admin interfaces showed no visual or behavioral changes, making the migration invisible to users and callers.

3. Elasticity

.NET Core runs on Linux, allowing the system to be deployed in Docker containers and scaled elastically via the internal cloud platform.

Main Process

1. Preparation

Compatibility gaps required recompiling or writing new components, extensive unit testing, and validation of stability.

.NET Core cannot use many .NET Framework components; they must be recompiled.

Some ASP.NET features are no longer supported and need custom adapters.

2. Compilation & Run‑Ready Phase

Upgrade projects bottom‑up, one by one.

Remove obsolete projects.

Start with low‑level libraries, then move upward.

For un‑compilable projects, temporarily replace calls with throw new NotImplementedException() to avoid runtime errors.

Compile the API layer first (no UI dependencies), then the Web layer, adjusting project structure and namespaces as needed.

After these steps the system became runnable, marking the first milestone.

3. Code Synchronization

Core code is managed in Git; a snapshot of the TFS history was pushed to Git, serving as the baseline for further upgrades and incremental feature development.

4. Testing

Developer self‑testing using an auto‑generated test suite and JMeter for large‑scale coverage.

Automated interface comparison tools verified data consistency, eliminating manual regression work.

QA performed targeted manual tests for critical scenarios such as author attribution and financial functions.

5. Gray Release

Uncovered edge cases were mitigated by gradually increasing traffic: 0.01 %, 1 %, 10 %, 50 %, then 100 % while monitoring logs, performance metrics, and error rates.

6. Full Switch

Switch order: PC → API → backend management → services → open APIs, each after successful validation. The complete rollout finished on June 6.

Experience

1. Backup Plan & Rollback

Maintain synchronized codebases and deployments for both old and new environments to enable instant rollback if critical issues arise.

2. Cautious Scaling

Premature scaling from 8 to 30 instances caused cascading performance degradation; identify single points of failure before expanding.

3. Self‑Test Tools

Developed custom tools for massive test case generation and interface comparison, reusable for future projects.

4. Logging Tools

Implemented middleware to capture request logs in Linux, forwarding them via UDP to the centralized ELK stack.

5. Monitoring Tools

Built a custom SDK to collect runtime metrics, shipped them to Logstash, indexed in Elasticsearch, and visualized with Grafana.

6. Cache Annotation

Ported Spring‑style cache annotations to .NET Core, dramatically reducing boilerplate code and improving TP99 latency (see before/after chart).

7. Cache Consistency

Recompiled ServiceStack.Redis to ensure both old and new systems share the same cache keys, saving roughly one‑third of integration effort.

8. JSON Framework Consolidation

Multiple JSON serializers (Json.NET, FastJson, MS Json) caused inconsistent responses; the plan is to standardize on a single serializer after migration.

9. Docker Performance

Limited data‑center resources forced a hybrid deployment: critical services in Docker, high‑traffic Web/API on VMs, with a future move to full containerization.

10. Run First, Fix Bugs Later

Prioritize getting a functional system up, then iteratively resolve technical issues to maintain team confidence.

Conclusion

The migration demonstrated a short learning curve for .NET Core, noticeable performance gains, and minimal code changes for many open‑source components. The experience produced reusable components and a reference architecture for future upgrades.

Appendix

1. Components

dotcoreActionMessageSdk – HTTP message queue

dotNews.ServiceStack.Redis – Redis connector

dotcoreAutohome.DataHelper – SQL Server connector

dotCoreCasClient – SSO component

dotcorejobclient – Distributed job scheduler

dotcoreNews.Comm – Common types

dotcoreNews.Common.Extends.Log – ELK logging

dotcoreNews.Common.Extends.Upload – Image upload

dotcoreNews.Common.UploadObject – File upload

dotcoreWebdiyer.MvcPagerCore – AJAX pagination

2. Compatibility Measures

dotcoreHttpContextCurrentCore – Emulates HttpContext.Current for ASP.NET Core.

Custom routing replaces removed WCF support.

Reimplemented Html.Action / Html.RenderAction.

EF Repository rewritten using SqlSugarCore.

Replaced Microsoft.Practices.ServiceLocation with Castle.Core.

Switched using System.Web.Mvc to Microsoft.AspNetCore.Mvc.

Areas replaced by router configuration.

ASHX handlers migrated to router middleware.

PreApplicationStartMethod replaced by Startup.cs calls.

HTTP handlers/modules converted to middleware.

3. Tool Support

Custom application metric monitor.

Batch test case generator.

Interface comparison tool.

JMeter for load testing.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendmigrationperformanceloggingDotnet Core
HomeTech
Written by

HomeTech

HomeTech tech sharing

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.