One of the most frequent questions that new users of ASP.NET Core MVC have is how to effectively show big volumes of data. WebForms developers frequently look for controls such as GridView, Repeater, or UpdatePanel. Nevertheless, ASP.NET Core MVC does not enable these controls because it takes a contemporary, performance-focused approach.

Beginning with basic ideas and progressing toward sophisticated, production-level solutions, this article discusses the proper and approved methods for displaying lakhs of entries in ASP.NET Core MVC.

Comprehending the Fundamental MVC Data Binding Idea
Data is not restricted by server controls in Core MVC. Rather, the view uses Razor and HTML syntax to render the data that the controller gives to it.
The essential guideline is:Never load all records at once. Always fetch only the data that the user needs.
This rule applies to all real-time applications such as IPO systems, banking portals, and admin dashboards.

Example Scenario
Assume we have an IPOmaster table with lakhs of records and the following fields:

• Symbol
• Category
• CreatedDate

Our goal is to display this data efficiently in a Core MVC application.

1. HTML Table with Razor – The First Step (Beginner Level)
This is the simplest and most important method to understand.
It replaces GridView and Repeater from WebForms.

The controller fetches only a small number of records using pagination.

Controller example:
public IActionResult IPOmaster(int page = 1)
{
    int pageSize = 20;

    var data = _context.IPOmaster
        .AsNoTracking()
        .OrderByDescending(x => x.CreatedDate)
        .Skip((page - 1) * pageSize)
        .Take(pageSize)
        .ToList();

    return View(data);
}

Why this is important:

•  AsNoTracking() improves performance
•  Skip and Take ensure only required rows are fetched
•  Memory usage stays low

View example:
<table class="table table-bordered">
    <thead>
        <tr>
            <th>Symbol</th>
            <th>Category</th>
            <th>Date</th>
        </tr>
    </thead>
    <tbody>
    @foreach (var item in Model)
    {
        <tr>
            <td>@item.Symbol</td>
            <td>@item.Category</td>
            <td>@item.CreatedDate</td>
        </tr>
    }
    </tbody>
</table>

This approach is mandatory knowledge for every MVC developer.

2. Partial View with AJAX – Beginner-Friendly Replacement for UpdatePanel
Beginners often ask how to update only part of the page without refreshing everything.

In Core MVC, this is done using Partial Views with AJAX.
Partial View (_IPOmasterList.cshtml):

<table class="table table-striped">
@foreach (var item in Model)
{
    <tr>
        <td>@item.Symbol</td>
        <td>@item.Category</td>
        <td>@item.CreatedDate</td>
    </tr>
}
</table>

Controller:
public IActionResult IPOmasterList(int page = 1)
{
    var data = GetPagedIPOData(page);
    return PartialView("_IPOmasterList", data);
}

Main View:
<div id="ipoContainer"></div>

<script>
function loadIPO(page) {
    $("#ipoContainer").load('/Admin/IPOmasterList?page=' + page);
}

$(document).ready(function () {
    loadIPO(1);
});
</script>

Why beginners should learn this:

• No full page reload
• Faster UI
• Works well for large datasets
• This is the accepted MVC version of UpdatePanel.

3. jQuery DataTables with Server-Side Processing – Advanced but Beginner-Understandable
When the application requires searching, sorting, and paging together, DataTables in server-side mode is the best solution.

Even though the code is advanced, the concept is simple:
The browser asks the server only for the data it needs.

View:
<table id="ipoTable" class="table table-bordered">
    <thead>
        <tr>
            <th>Symbol</th>
            <th>Category</th>
            <th>Date</th>
        </tr>
    </thead>
</table>

<script>
$('#ipoTable').DataTable({
    processing: true,
    serverSide: true,
    ajax: {
        url: '/Admin/GetIPOData',
        type: 'POST'
    },
    columns: [
        { data: 'symbol' },
        { data: 'category' },
        { data: 'createdDate' }
    ]
});
</script>

Controller:
[HttpPost]
public IActionResult GetIPOData()
{
    var request = HttpContext.Request.Form;

    int start = int.Parse(request["start"]);
    int length = int.Parse(request["length"]);

    var query = _context.IPOmaster.AsNoTracking();
    int totalRecords = query.Count();

    var data = query
        .OrderByDescending(x => x.CreatedDate)
        .Skip(start)
        .Take(length)
        .Select(x => new {
            symbol = x.Symbol,
            category = x.Category,
            createdDate = x.CreatedDate.ToString("dd-MM-yyyy")
        })
        .ToList();

    return Json(new {
        draw = request["draw"],
        recordsTotal = totalRecords,
        recordsFiltered = totalRecords,
        data
    });
}

Why this is important:

• Handles lakhs of records easily
• Search and sort happen on the server
• Used in real enterprise systems

4. ViewComponent – Clean and Reusable (Advanced Concept Explained Simply)
ViewComponents are useful when the same data grid appears in multiple places.

ViewComponent:
public class IPOmasterViewComponent : ViewComponent
{
    public IViewComponentResult Invoke(int page = 1)
    {
        var data = GetPagedIPOData(page);
        return View(data);
    }
}

View usage:
@await Component.InvokeAsync("IPOmaster", new { page = 1 })

For beginners:
Think of ViewComponent as a mini-controller + view

Keeps code clean and reusable

Final Recommendation for Beginners
Start with:
HTML Table + Razor

Then move to:
Partial View + AJAX

Finally adopt:
jQuery DataTables (Server-side) for large data
Avoid loading all records at once. This is the most common beginner mistake.

Conclusion
ASP.NET Core MVC encourages developers to think in terms of performance and scalability. By learning simple Razor tables first and gradually moving to AJAX and server-side DataTables, even beginners can build applications that handle lakhs of records efficiently. These techniques are not only beginner-friendly but also production-ready.

As a developer, I can't even begin to count how many times a customer has called me following a deployment because they can't see any of the changes that were made (or something isn't working). There are several methods to react to this, but it typically entails going into options or holding one key while pushing another.

Although I don't particularly enjoy this approach, the most recent version of ASP.NET makes it possible for me to quickly resolve this problem by using TagHelpers.

Caching and Issues with It
Caching issues generally result from a browser holding onto an older version of a file after it has been changed.

This is usually a good thing for everyone as the server is happy because it doesn't have to serve out a file that it has already served to a client and the client is happy because they experienced zero load-time for the file. It sounds a bit like a win-win scenario, however, when some of these files that were being cached are changed after a release or deployment, things can go horribly, horribly wrong.

Non-cached objects of an application will now be talking to older versions of files, script files may be relying on DOM elements that either no longer exist or simply don't exist yet, CSS rules can change and cause your application to look strange or worse, your application may not simply work at all.

Fixing Caching Issues
Caching issues are usually resolved at the client-level or more specifically by the end-user. The following is an exchange that you may have taken part in previously or just an example of one that could occur:

• Developer: "Well, we deployed the update this morning. Everything should be working along with all of the new features."
• Client: "I just tried accessing it and everything looks funny, besides that, nothing seems to work."
• Developer: "You may need to clear your cache for the changes to take effect."
• Client: "Cache? Haven't I paid you folks enough already?"
• Developer: "No, the cache in your browser. It's storing the older files prior to the update and you need to get rid of them."
• Client: "Well how do I do that?"
• Developer: "You can either go into Options within your browser and choose the Clear Temporary Files option or hold the CTRL key and press F5. You should see a flicker and then it should work."
• Client: "Yep. I just did that and it seemed to fix it. Now do I need to do this every time that I open the application or site?"

The issue with this scenario is that it should not be the responsibility of the end user to have to clear their cache every time something happens.

How Caching Can Mess You Up?
Files are cached in different configurable ways, but the most common case where a file is being cached unnecessarily is also the most common way the file is referenced.

Let's take the popular client-side library jQuery for example and assume we are referencing it within our web application:
    <script src="~/Scripts/jquery.js"></script>   

There isn't really anything wrong with this - and if caching is enabled after the first time it is requested, the jquery.js file will be stored locally within the cache and will not be requested from the server again. As I mentioned earlier, this is great as it reduces overhead to the server and will speed up load times since the file is being accessed locally.

The problem comes in when the developer decides to upgrade the version of jQuery and we aren't generally talking about minor updates which will not introduce major breaking changes, but let's use the leap from jQuery 1.x to jQuery 2.x. This release changed all sorts of APIs, removed support for older browsers and did quite a few other things that could break an application.

Now if the user has the previous version cached and you revisit the application after changing quite a bit of your markup, the newer markup should be picked up, but the older jQuery file is still going to be used, which is not what we want.

Removing Caching Entirely
One of the most common solutions to get around this is to simply remove caching entirely. This is usually done by appending a randomly generated query string parameter that uses something like a timestamp as seen below :
    <!-- This might render something like "~/Scripts/jquery.js?dt=123456789" -->   
    <script src="~/Scripts/jquery.js?dt=@(DateTime.Now.Ticks)"></script>   

This will append a timestamp to the end of your jQuery request each time. The server uses the querystring parameters to differentiate between individual requests and thus it would load your jQuery file from the server every time.

Sure, this resolves the issues of always serving the user the proper file, but it is terribly inefficient. It negates all of the benefits of caching and simply results in longer load times and additional server overhead.

"Cache-busting”: A Versioned Approach
A more effective version of the previous approach might be to append a version number of your application as a querystring parameter. This would ensure that all of your resources would contain the version number of the current release similar to the following example:
    <!-- This might render something like "~/Scripts/jquery.js?v=1.1" -->   
    <script src="~/Scripts/jquery.js?v=@(YourApplicationVersionNumber)"></script>   

This is commonly referred to as "cache-busting" and it's a nice balance to strike when deploying new versions of an application. Basically, once a release is pushed out, you'll simply need to update the version number for your application and it will automatically pull the latest versions from the server and cache them (ignoring the older versions entirely).

Using TagHelpers to Cache-bust
One of the most interesting features of ASP.NET MVC6 is the introduction of TagHelpers. Now this post isn't a crash course on them, but if you want to learn a bit more, I'd recommend reading through Jeff Fritz's blog post on them here and this MSDN article on them.

In a nutshell, TagHelpers allow developers to use a bit of magic within their ASP.NET MVC Views and are really designed to be cleaner, better versions of the existing HtmlHelpers that are used today.

With regards to cache-busting, there is going to be one specific attribute that we will be discussing, and that is the asp-append-version attribute. With the use of TagHelpers, simply appending this attribute will function similar to the versioned cache-busting approach mentioned above.

You'll now just need to use the following to ensure the proper version of your file is used,
    <!-- This might render something like "~/Scripts/jquery.js?v=is_TDV8iLgND2WN04JRVo613wYNCbRcGd_y8caHTLZE" -->   
    <script asp-append-version="true" src="~/Scripts/jquery.js"></script>  

That's it. Simply append asp-append-version="true" to any <script>,<link> or <style> tag and it should add a query string value that corresponds to a specific version of that file.

What's great about this? 

• It's easy. There's no server-side code to add or values to adjust, simply append a single attribute and it works.
• It's automatic. You don't have to worry about manually updating a version for your project, since the version is based off of the file itself, .NET handles all of that for you.
• No more calls. Since this handles busting the cache, you don't have to worry about clients calling complaining that "things look weird" as this will ensure they are served the proper file.
• It's smart. Another benefit that this approach offers over some of the alternatives is that it will only bust the cache for files that need it. If your site.css file didn't change since the last deployment, it should still be cached and its version number shouldn't change.

What do I need to do?
To actually take advantage of the TagHelpers like this one, you don't have to do a whole lot. In fact, you can simply add the following line at the top of any Views that take advantage of the them and they will just work:
    @addTagHelper "*, Microsoft.AspNet.Mvc.TagHelpers"  

It is not a straightforward version bump to upgrade an ASP.NET MVC application from the.NET Framework to the current.NET. The runtime, hosting model, configuration system, dependency injection, and HTTP pipeline architecture have all changed as a result of this migration. Many teams undervalue this and handle it like a typical framework upgrade, only to find out later on that their application's fundamental presumptions are no longer valid.

The good news is that Microsoft provides clear guidance and patterns that make this migration predictable when approached correctly. This article walks through a practical, step by step strategy to migrate an ASP.NET MVC 5 application built on .NET Framework to ASP.NET Core running on modern .NET, while minimizing risk and downtime.

This guide is written for developers who already understand ASP.NET MVC and want a realistic, production ready path forward.

Step 1: Choose your migration path based on app size

• Pick one of these two paths

• Incremental migration for most real apps
  You stand up a new ASP.NET Core app in front of the old app and move routes and features over gradually, keeping the old app live while you migrate. Microsoft recommends this approach for large migrations.
• Big bang migration for small apps 
  You create a new ASP.NET Core MVC app and port controllers, views, and services until everything runs, then you cut over.

If you are unsure, default to incremental migration because it reduces cutover risk.

Step 2: Inventory what will block you
List dependencies and app features that commonly need work during migration

• System.Web usage
  Things like HttpContext.Current, HttpModules, HttpHandlers, Global.asax, and classic pipeline features do not carry over as is.
• Authentication and authorization
  ASP.NET Core uses a different model.
• Session, caching, config, logging
  APIs and patterns differ and need deliberate migration planning.

Make a quick compatibility pass on your NuGet packages

• For each package, check if it supports netstandard2.0 or modern net versions, or if there is an ASP.NET Core replacement.
• Flag anything tied to System.Web.

Step 3: Create a safe baseline before touching code

• Freeze the current state
  • Tag the repo.
  • Ensure you can build the solution and run your test suite.

• Add or strengthen tests if you are light on coverage
  • Focus on critical routes, auth flows, and the top business actions.
  • If you cannot add tests quickly, at minimum record smoke test scripts and expected outputs.

Step 4: Upgrade libraries first, before the web app
This is the highest leverage move.
Split your solution into layers, if it is not already

Web project, application services, domain, data access, shared utilities.

Port class libraries first

Convert libraries to target netstandard2.0 when possible as a bridge, or target modern .NET directly if you can.

Fix compile errors and replace unsupported APIs.

Microsoft’s general porting guidance is to assess the project and move pieces in a way that reduces complexity after the initial upgrade.

Step 5: Decide whether to use migration tooling
You have two Microsoft supported tool directions you can use to speed up parts of the work.

• .NET Upgrade Assistant
  It helps upgrade projects and analyze incompatibilities, including .NET Framework projects. Use it where it helps, but do not expect it to fully transform an ASP.NET MVC 5 app into ASP.NET Core MVC automatically.

• Migration tooling for ASP.NET Framework apps
  Microsoft points to dedicated modernization tooling for upgrading ASP.NET Framework MVC, Web API, and Web Forms projects to ASP.NET Core.

You can still do everything manually if you prefer, but tooling can reduce boring mechanical edits.

Step 6: Create the new ASP.NET Core MVC host app
This step is required even in incremental migration because you need an ASP.NET Core app to run on modern .NET.

Create a new ASP.NET Core MVC project

• Use the standard ASP.NET Core MVC template.
• Add your core packages, logging, config, and DI structure.

Set up the modern entry point

• In ASP.NET Core, Program.cs configures the host and middleware pipeline.
• There is no Global.asax.

Add basic middleware you will definitely need

• Routing
• Static files
• Authentication and authorization, if applicable
• MVC endpoints

Minimal example shape:
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();

var app = builder.Build();

app.UseStaticFiles();
app.UseRouting();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

Step 7: Move routes first, then controllers, then views
Microsoft’s MVC to Core example walkthrough starts with setup, then controllers and views, then static content and client dependencies. Follow that order because it keeps the migration testable at every step.

Migrate routing

• In MVC 5 you likely used RouteConfig and possibly attribute routes.
• In ASP.NET Core you configure routing in the middleware pipeline and endpoint mappings.

Migrate one controller at a time

• Copy a controller class.
• Fix compile errors by switching namespaces and replacing System.Web dependent code.
• Replace HttpContext.Current patterns with controller HttpContext access.

Migrate views

• Razor syntax is similar, but helpers and some features differ.
• Convert HTML helpers where needed, and use Tag Helpers where it makes sense.

Migrate partials, layouts, and shared view imports

• You will likely introduce ViewImports.cshtml and ViewStart.cshtml patterns.

Step 8: Move static files and client side dependencies

• Static files
  • In MVC 5 you may have used Content and Scripts conventions.
  • In ASP.NET Core, the default is wwwroot plus UseStaticFiles middleware.
• Bundling and minification
  If you relied on System.Web.Optimization, replace it with a modern frontend build pipeline or another supported approach.

Microsoft’s example migration flow explicitly calls out static content and client side dependencies as an early migration step.

Step 9: Migrate configuration from Web.config to appsettings

• Identify what you store in Web.config
  • Connection strings
  • App settings
  • Authentication settings
  • Custom config sections
• Move settings into appsettings.json and environment specific appsettings files
• Read settings using the ASP.NET Core configuration system via builder.Configuration

Microsoft has dedicated guidance linked from the MVC migration example for migrating configuration.

Step 10: Migrate authentication and authorization
Identify your current auth model

• Forms auth
• OWIN cookies
• ASP.NET Identity in MVC 5
• Windows auth

Implement the equivalent in ASP.NET Core

• Configure authentication services in DI.
• Add middleware in the pipeline.
• Port authorization attributes and policies.

Microsoft’s MVC migration example points to dedicated guidance for migrating authentication and Identity because it is usually one of the heavier parts.

Step 11: Migrate data access
If you use Entity Framework 6

• You can often keep EF6 for a while, even on modern .NET, depending on your setup.
• Longer term, many teams move to EF Core for modern patterns and features.

If you use ADO.NET or Dapper
These typically port cleanly, but you will update configuration and dependency injection patterns.

Step 12: Run the app, fix runtime issues, then optimize

Build and run locally

Fix runtime issues in this typical order

    Configuration and environment differences

    Middleware ordering problems

    Auth and cookies

    Session and caching behavior

Run automated tests and smoke tests

Add structured logging and health checks where appropriate

Step 13: If you chose incremental migration, set up the “front door” Core app

For incremental migration, the key move is putting an ASP.NET Core app in front of the existing .NET Framework app and migrating route by route. Microsoft’s “get started” guidance for incremental migration recommends this proxy front approach for large migrations.

Your process becomes:

Route A handled by ASP.NET Core, everything else proxies to MVC 5

Move one vertical slice at a time

When all routes are moved, retire the old MVC 5 app

Step 14: Production cutover checklist

Hosting
Decide IIS in process, IIS out of process, or container.

Observability
Logs, metrics, tracing aligned across both apps during incremental migration.

Security
Cookie settings, data protection keys, TLS, headers

Performance
Confirm caching and session behavior after migration.

Final Thoughts
Migrating an ASP.NET MVC application from .NET Framework to modern .NET is a strategic investment, not a mechanical upgrade. When done correctly, it results in a cleaner architecture, improved performance, better cloud readiness, and long term platform support.By breaking the migration into deliberate, testable steps and focusing first on architecture rather than syntax, teams can modernize confidently without disrupting production systems.

This approach has proven to work repeatedly in real world enterprise migrations and aligns with Microsoft’s recommended modernization strategy for ASP.NET applications.