diff --git a/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/mongo-db.jpg b/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/mongo-db.jpg
new file mode 100644
index 0000000000..a829bc28b4
Binary files /dev/null and b/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/mongo-db.jpg differ
diff --git a/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/post.md b/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/post.md
new file mode 100644
index 0000000000..ddae9a3704
--- /dev/null
+++ b/docs/en/Community-Articles/2025-06-12-fix-mongodb-guid-abp-v9.2.0-upgrade/post.md
@@ -0,0 +1,93 @@
+# Solving MongoDB GUID Issues After an ABP Framework Upgrade
+
+So, you've just upgraded your ABP Framework application to a newer version (like v9.2.0+) and suddenly, your application can't read data from its MongoDB database. You're seeing strange deserialization errors, especially related to `Guid` types. What's going on?
+
+You've likely run into a classic compatibility issue with the MongoDB .NET driver.
+
+### The Problem: Legacy vs. Standard GUIDs
+
+Here's the short version:
+
+* **Old MongoDB Drivers** (used in older ABP versions) stored `Guid` values in a format called `CSharpLegacy`.
+* **New MongoDB Drivers** (v3.0+), now default to a universal `Standard` format.
+
+When your newly upgraded app tries to read old data, the new driver expects the `Standard` format but finds `CSharpLegacy`. The byte orders don't match, and... boom. Deserialization fails.
+
+The ABP Framework team has an excellent official guide covering this topic in detail. We highly recommend reading their **[MongoDB Driver 2 to 3 Migration Guide](https://abp.io/docs/latest/release-info/migration-guides/MongoDB-Driver-2-to-3)** for a full understanding.
+
+Our tip below serves as a fast, application-level fix if you need to get your system back online quickly without performing a full data migration.
+
+### The Quick Fix: Tell the Driver to Use the Old Format
+
+Instead of changing your data, you can simply tell the new driver to continue using the old `CSharpLegacy` format for all `Guid` and `Guid?` properties. This provides immediate backward compatibility without touching your database.
+
+It’s a simple, two-step process.
+
+#### Step 1: Create a Custom Convention
+
+First, create this class in your `.MongoDb` project. It tells the serializer how to handle `Guid` types.
+
+```csharp
+using MongoDB.Bson;
+using MongoDB.Bson.Serialization;
+using MongoDB.Bson.Serialization.Conventions;
+using MongoDB.Bson.Serialization.Serializers;
+using System;
+
+public class LegacyGuidConvention : ConventionBase, IMemberMapConvention
+{
+    public void Apply(BsonMemberMap memberMap)
+    {
+        if (memberMap.MemberType == typeof(Guid))
+        {
+            memberMap.SetSerializer(new GuidSerializer(GuidRepresentation.CSharpLegacy));
+        }
+        else if (memberMap.MemberType == typeof(Guid?))
+        {
+            var guidSerializer = new GuidSerializer(GuidRepresentation.CSharpLegacy);
+            var nullableGuidSerializer = new NullableSerializer<Guid>(guidSerializer);
+            memberMap.SetSerializer(nullableGuidSerializer);
+        }
+    }
+}
+```
+
+#### Step 2: Register the Convention at Startup
+
+Now, register this convention in your `YourProjectMongoDbModule.cs` file. Add this code to the top of the `ConfigureServices` method. This ensures your rule is applied globally as soon as the application starts.
+
+```csharp
+using Volo.Abp.Modularity;
+using MongoDB.Bson.Serialization;
+using MongoDB.Bson.Serialization.Conventions;
+
+public class YourProjectMongoDbModule : AbpModule
+{
+    public override void ConfigureServices(ServiceConfigurationContext context)
+    {
+        // Fix Start
+        var conventionPack = new ConventionPack { new LegacyGuidConvention() };
+        ConventionRegistry.Register(
+            "LegacyGuidConvention",
+            conventionPack,
+            t => true); // Apply to all types
+        // Fix End
+
+        // ... Your existing ConfigureServices code
+    }
+}
+```
+
+### An Alternative to Full Data Migration
+
+It's important to note that the method described here is an **application-level fix**. It's a fantastic alternative to performing a full data migration, which involves writing scripts to convert every legacy GUID in your database.
+
+If you are interested in the more permanent, data-centric approach, the ABP.IO community has a detailed guide on [**Migrating MongoDB GUIDs from Legacy to Standard Format**](https://abp.io/community/articles/migrating-mongodb-guids-from-legacy-to-standard-format-mongodb-v2-to-v3-dqwybdtw).
+
+Our quick fix is ideal for getting a system back online fast or when a database migration is too complex. The full migration is better for long-term standards compliance. Choose the path that best fits your project's needs!
+
+### That's It!
+
+Restart your application, and the errors should be gone. Your app can now correctly read its old `Guid` data, and it will continue to write new data in the same legacy format, ensuring consistency.
+
+This approach is a lifesaver for existing projects, saving you from a risky and time-consuming data migration. For brand-new projects, you might consider starting with the `Standard` representation, but for everything else, this is a clean and effective fix. Happy coding!