Legacy Cycle Store MVC: .NET Modernization Starting Point

The Legacy Cycle Store MVC app is a classic ASP.NET MVC 4 web application backed by Entity Framework 5 and a SQL Server database hosted on Amazon RDS. Built on the familiar AdventureWorks dataset, it presents a working cycle-products storefront — complete with categories, subcategories, and product listings — targeting .NET Framework 4.5. This repository is Part 1 of a multi-part AWS Samples series that walks you through the full journey of taking an existing .NET Framework application and modernizing it for the cloud: first getting the legacy app running on AWS infrastructure, then migrating to ASP.NET Core 3.1 with EF Core, and finally containerizing the result with Docker.

Why Modernize?

Tens of thousands of .NET applications run across the world, many of which are ASP.NET web applications. For years, .NET Framework was the canonical runtime for Windows-hosted web workloads. That landscape has changed permanently: Microsoft’s unified platform strategy converges all future investment into a single cross-platform .NET — and that platform is built on .NET Core, not .NET Framework.

.NET 5.0 is built on .NET Core, not .NET Framework. This means that applications targeting .NET Framework 4.8 and lower cannot automatically upgrade to .NET 5.0. Moving from any 4.x version to .NET 5+ requires deliberate refactoring to resolve breaking API changes.

The practical consequences are significant:

No direct upgrade path. Package-by-package porting, API shim removal, and EDMX-to-EF-Core migration are all required steps — none of which happen automatically.
Cross-platform reach. Once ported to .NET Core, your application can run on Linux, enabling container-based deployments on Amazon ECS, Amazon EKS, or AWS Fargate without a Windows Server license.
Long-term support alignment. .NET Framework 4.x remains in maintenance mode with no new features. All active runtime investment — performance, minimal APIs, gRPC, native AOT — is exclusively in the .NET Core lineage.
Ecosystem compatibility. Modern NuGet packages, AWS SDK for .NET v3, and cloud-native tooling target netstandard2.x or net6+, not net45.

Understanding why modernization is necessary is the first step. This project gives you a concrete, runnable starting point so you can observe the legacy patterns before you replace them.

What This Project Is

The application is an online cycle store powered by the AdventureWorks product dataset — the same dataset Microsoft has used in documentation and samples for decades. The subset used here focuses on three production tables: Product, ProductCategory, and ProductSubcategory, organized under the Production schema in a SQL Server database named CYCLE_STORE. The data layer is built with Entity Framework 5 Database-First using an EDMX model file (CycleModel.edmx). This approach was standard for enterprise .NET 4.x projects: you point the Visual Studio designer at a live database, generate the EDMX XML model and T4-templated C# entity classes, and bind them through a DbContext subclass. It is exactly the kind of setup you will encounter in legacy codebases in the wild. The presentation layer is ASP.NET MVC 4 with Razor views. A master layout file (_SiteLayout.cshtml) drives the page shell, and child action calls render the header and content areas as partial views. Routing follows the conventional {controller}/{action}/{id} pattern with a default landing on Home/Default. The database is hosted on Amazon RDS SQL Server Express, provisioned through an AWS CloudFormation template included in the repository. Secrets Manager stores the database credentials, and an IAM Role grants the RDS instance permission to use the SQLSERVER_BACKUP_RESTORE option for S3-backed native backups. The key NuGet packages that define the legacy technology stack are:

<!-- packages.config -->
<packages>
  <package id="EntityFramework"          version="5.0.0"         targetFramework="net45" />
  <package id="Microsoft.AspNet.Mvc"     version="4.0.20710.0"   targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi"  version="4.0.20710.0"   targetFramework="net45" />
  <package id="Microsoft.AspNet.Razor"   version="2.0.20715.0"   targetFramework="net45" />
  <package id="Newtonsoft.Json"          version="13.0.1"         targetFramework="net45" />
</packages>

All of these are .NET Framework-only packages. EntityFramework 5.x and Microsoft.AspNet.Mvc 4.x have no netstandard or netcoreapp targets — they are the exact pain points you will address in Part 2.

Two Modernization Choices

When facing a .NET Framework 4.x application, development teams typically have two realistic paths forward:

Wait for .NET 5
Migrate to .NET Core 3.1 Now

Strategy: Hold and migrate directly to .NET 5 when it ships.This approach defers all refactoring work until the target platform is GA and its ecosystem (NuGet packages, tooling, documentation) has stabilized. It avoids chasing a moving target and keeps the team focused on feature delivery in the short term.Trade-offs to consider:

The migration scope from .NET Framework 4.x to .NET 5 is identical to the scope from 4.x to .NET Core 3.1. Nothing about waiting reduces the actual porting effort.
Your application remains locked to Windows Server during the wait period, delaying any cost or operational benefits from Linux-based container deployments.
Breaking changes discovered late — deep EDMX dependencies, System.Web usage, Windows-only APIs — will still require the same resolution effort, but under more time pressure if there is a hard cut-off date.
Third-party packages that target net45 may not have net5.0 equivalents ready at the moment you need them.

This path is reasonable for teams with high feature velocity and low operational urgency on modernization, but it does not reduce technical debt — it defers it.

Strategy: Begin migrating to ASP.NET Core 3.1 + EF Core now for a smoother .NET 5 transition..NET Core 3.1 is a Long-Term Support (LTS) release. Applications running on it can upgrade to .NET 5 with minimal friction because both share the same runtime model, dependency injection container, middleware pipeline, and EF Core API surface. Starting the migration now means the hardest work — rewriting System.Web dependencies, replacing EDMX with EF Core DbContext, adapting MVC conventions — is done in an LTS window with full community support.Benefits of this approach:

Incremental deliverables. Each part of this series produces a deployable artifact: a working legacy app, a working .NET Core app, and a containerized app. The team gains confidence and visibility at every step.
Cross-platform immediately. Once on .NET Core 3.1, the application can run on Linux and be containerized for Amazon ECS or EKS, which is the subject of Part 3.
EF Core migration is the same work regardless of timing. The EDMX model must be replaced with a code-first DbContext whether you target Core 3.1 or .NET 5 — doing it on 3.1 gives you more runway.
Lower .NET 5 upgrade cost. The .NET Upgrade Assistant and SDK-style project files make the 3.1 → 5 hop largely mechanical once the platform rewrite is done.

This is the path this series demonstrates, starting with Part 1 (this repository).

Series Overview

This documentation covers a three-part modernization series. Each part builds directly on the previous one:

Part 1 — Run the Legacy App on AWS (This Repository)

Get the original ASP.NET MVC 4 / Entity Framework 5 application running against a SQL Server Express database on Amazon RDS. The CloudFormation template (SqlServerRDSFixedUidPwd.yaml) provisions the full AWS infrastructure — RDS instance, Secrets Manager secret, IAM Role, and Security Group — so you have a faithful replica of the legacy production environment before any code changes are made.Goal: Understand what you are modernizing. Confirm all three application tiers (presentation, business, data) work end-to-end on AWS.

Part 2 — Migrate to ASP.NET Core 3.1 + EF Core

Replace the .NET Framework dependencies with their .NET Core equivalents. This involves migrating from Microsoft.AspNet.Mvc 4 to Microsoft.AspNetCore.Mvc, from Entity Framework 5 EDMX to EF Core with a code-first DbContext, and from System.Web-based configuration to the ASP.NET Core middleware pipeline and appsettings.json.Goal: A functionally equivalent application running on .NET Core 3.1, deployable on both Windows and Linux.

Part 3 — Containerize with Docker and Deploy on AWS

Package the ASP.NET Core application into a Docker image and deploy it to AWS using Amazon ECS or Amazon EKS. This step unlocks the full operational benefits of cloud-native deployment: automated scaling, rolling updates, infrastructure-as-code, and elimination of Windows Server licensing costs.Goal: A containerized application deployed to AWS with a reproducible CI/CD pipeline.

Solution Architecture

Explore the three-tier architecture: MVC presentation layer, EF5 business layer, and RDS SQL Server data layer.

Prerequisites

Review the AWS account, Visual Studio, and .NET Framework requirements before you begin.

Modernization Overview

Understand the full scope of changes required to move from .NET Framework to .NET Core.

Project Structure

Walk through the Visual Studio solution layout, directory structure, and key source files.

Overview

Getting Started

Application Deep Dive

Modernization Path

Reference

Legacy Cycle Store MVC: .NET Modernization Starting Point

Why Modernize?

What This Project Is

Two Modernization Choices

Series Overview

Solution Architecture

Prerequisites

Modernization Overview

Project Structure

Build docs developers (and LLMs) love

Overview

Getting Started

Application Deep Dive

Modernization Path

Reference

Documentation Index

​Why Modernize?

​What This Project Is

​Two Modernization Choices

​Series Overview

Solution Architecture

Prerequisites

Modernization Overview

Project Structure

Build docs developers (and LLMs) love

Why Modernize?

What This Project Is

Two Modernization Choices

Series Overview