DEV Community: Mohammad Alhraki

What System Migration Really Is (And Why It’s Not Database Migration)

Mohammad Alhraki — Mon, 29 Dec 2025 13:41:37 +0000

System migration is one of the most misunderstood challenges in software and business. It is often described as a technical task: move data from one system to another, map fields, validate results, train users, and move on.

In reality, system migration is one of the few engineering efforts where code is the smallest part of the problem.

You are not migrating data. You are migrating how people run their business.

What you’ll learn from this article

Why system migration is not database migration
How technical data migration fits into a larger business process
What usually goes wrong during migrations — and why
How engineers, managers, and owners should approach migration differently
What actually makes a migration succeed or fail

Step 1: Understand That You Are Migrating a Business, Not Data

Before writing a single script or mapping a single field, accept this: Systems encode rules, assumptions, and behavior — not just data.

Changing the system means changing how work gets done.

❌ Common mistake
Treating system migration as an IT task that can be executed independently.

✅ Better approach
Understand the business workflows before touching the data. Ask how things are done, not just how they are stored.

Step 2: Separate Strategic Decisions From Operational Pain

System migration usually starts at the leadership level. Owners migrate because they want:

Better visibility
Stronger control
Scalability
Long-term stability

However, users experience something very different:

Loss of familiar workflows
Loss of shortcuts
Loss of speed
Fear of making mistakes

Migration is approved by leadership, but judged by daily users.

❌ Common mistake
Assuming users will accept the new system simply because the decision is final.

✅ Better approach
Treat resistance as a signal. It often reveals gaps in expectations, training, or communication — not system failure.

Step 3: Accept That Legacy Systems Store Behavior, Not Just Data

Legacy systems rarely survive because they are clean or correct. They survive because they are permissive.

They allow incomplete records, manual overrides, flexible interpretations, and silent inconsistencies. Over time, workarounds become habits, and habits become “how the business works.”

When a new system enforces structure, users often say:

“This is wrong”
“This is more complicated”
“The old system was better”

What they usually mean is: The old system allowed me to work around problems.

❌ Common mistake
Trying to replicate every legacy behavior in the new system.

✅ Better approach
Decide deliberately:

What behavior must be preserved

What behavior must be corrected

What behavior should be dropped

This is a business decision, not a technical one.

Step 4: Do the Technical Migration — Carefully and Honestly

Technical data migration is real work and it matters. Engineers still need to extract legacy data safely, map entities, transform structures, and validate totals. This work is complex, risky, and requires discipline.

But even a technically perfect migration can still fail the business.

❌ Common mistake
Assuming that “correct data” guarantees success.

✅ Better approach
Optimize for clarity and traceability, not just correctness. A known gap is safer than a hidden inconsistency.

Step 5: Treat Validation as a Trust-Building Exercise

Every migration eventually reaches the same moment. Someone looks at a report and asks: “Why doesn’t this match what we had before?”

The answer is rarely simple. Rules, assumptions, interpretations, and structures have all changed. A less experienced engineer tries to prove the system is correct. A more experienced one understands that being right is useless if no one believes you.

❌ Common mistake
Defending the system instead of explaining it.

✅ Better approach
Explain what changed, why it changed, and what cannot be replicated exactly. Transparency builds trust. Perfection does not.

Step 6: Understand That Training Is About Unlearning

Training during migration is not about features. It is about:

Breaking muscle memory
Replacing habits
Reducing fear of mistakes

Users are not learning a new system. They are unlearning years of behavior.

❌ Common mistake
Relying only on documentation or demos.

✅ Better approach
Explain why things are different, not just how to use them. Empathy becomes a technical requirement.

Step 7: Engineers Must Act as Translators

During system migration, engineers stop being just engineers. They become:

Translators between business intent and system rules
Interpreters of historical data
Mediators between owners and users
Guardians of long-term structure

You explain systems to people, and people to systems. This role determines success more than any script or tool.

Step 8: Help Owners Understand What Pain Really Means

Migration pain does not automatically mean failure. Often, it means reality is becoming visible, control is replacing flexibility, or old assumptions are being challenged.

When a new system feels stricter, it is often because the old one was forgiving mistakes.

❌ Common mistake
Reacting to every complaint by weakening the system.

✅ Better approach
Distinguish between productive discomfort and real usability problems. Only one of them should be fixed in code.

Final Thought

If system migration were only about moving data, it would already be a solved problem. It isn’t.

Because system migration is not database migration.

It is business transformation carried out through technology — while the business is still running. That is why successful migrations require clear decisions, honest communication, respect for people, and restraint in technical compromises.

TL;DR

System migration is a business transformation, not a data task.
Technical migration is necessary but not sufficient.
User trust matters more than perfect data.
Engineers must act as translators, not just developers.
Migration success depends on people, not tools.

Can I solve Advanced Problem- with GPT as a Software Engineer?

Mohammad Alhraki — Thu, 21 Mar 2024 20:59:03 +0000

Introduction

Tackling intricate coding problems requires a detailed approach. This guide will walk you through a complex issue in TypeScript, demonstrating how to effectively communicate with GPT for advanced solutions.

Step 1: Detail Your Complex Problem

Clearly describe the advanced issue you’re facing. For example:

“I’m working on a TypeScript project involving asynchronous operations with Promises and async/await. I’ve encountered a type mismatch error when trying to compile my code.”

Step 2: Provide a Challenging Code Snippet

Share a complex code snippet that illustrates the problem:


async function processFiles(files: string[]): Promise<void> {
    try {
        for (const file of files) {
            const content: string = await readFile(file);
            const processedContent: string = await processContent(content);
            await writeFile(file, processedContent);
        }
    } catch (error) {
        console.error(‘Error processing files:’, error);
    }
}

// Assume readFile and writeFile return Promises and processContent is an async function

Step 3: Ask In-Depth Questions

Pose detailed questions to guide GPT towards the solution:

“Why am I receiving a type mismatch error when all functions involved return a Promise of type string?”

Step 4: Explore GPT’s Expertise

GPT can assist with complex tasks, including:

Advanced Debugging: “Can you help identify the cause of this type error in my async function?”
TypeScript Best Practices: “What are some best practices for handling errors in asynchronous TypeScript code?”

Step 5: Participate in a Detailed Dialogue

Be prepared for GPT to ask technical questions to clarify the issue:

GPT: “Are the readFile and writeFile functions properly typed to handle Promises?”
You: “Yes, they are typed as follows: function readFile(path: string): Promise<string>”

In conclusion

By providing a detailed description, complex code examples, and engaging in a technical dialogue, you can harness GPT’s capabilities to solve sophisticated TypeScript problems.

Understanding Database Normalization and the Importance of 1NF

Mohammad Alhraki — Fri, 15 Mar 2024 14:58:25 +0000

What is Database Normalization?

Database normalization is a fundamental principle in database design. Its purpose is to organize data efficiently, reduce redundancy, and maintain data integrity. By adhering to normalization rules, we create well-structured databases that facilitate data processing and querying.

Why Choose Normalization?

The main reasons for employing database normalization include:

Avoiding Complexity: Breaking down data into smaller, related tables simplifies management.
Eliminating Redundancy: Ensuring each piece of information appears only once.
Consistent Organization: Structuring data according to specific rules.

Types of Normalization

Let's focus on the first three levels of normalization:

1. First Normal Form (1NF)

1NF establishes the foundation for more complex normalization strategies. Here are its key characteristics:

Each cell in a table holds only one value (this is called atomicity).
A primary key uniquely identifies each row.
No duplicated rows or columns.
Each column contains only one value for each row.

2. Second Normal Form (2NF)

2NF builds upon 1NF:

All non-key attributes are fully functionally dependent on the entire primary key.
Helps eliminate partial dependencies.

3. Third Normal Form (3NF)

3NF further refines the design:

All non-key attributes are directly dependent on the primary key.
Helps eliminate transitive dependencies.

Examples of 1NF, 2NF, and 3NF

1NF Example

Consider an employee database with the following table:

Employee ID	Name	Sales
1	Shaun	$500
2	Dave	$400
3	Steve	$500
4	Jennifer	$800
5	Sierra	$750

In this 1NF-compliant table:

Each cell holds a single value.
The primary key is the Employee ID.
There are no duplicate rows or columns.

2NF Example

Suppose we have another table for employee data:

Employee ID	Employee Name	Department
1	Shaun	Sales
2	Dave	Sales
3	Steve	Marketing
4	Jennifer	Finance
5	Sierra	Finance

In this 2NF-compliant table:

All non-key attributes are fully functionally dependent on the entire primary key.

3NF Example

Continuing with the employee_data table, let's further normalize it:

Employee ID	Employee Name	Department ID
1	Shaun	1
2	Dave	1
3	Steve	2
4	Jennifer	3
5	Sierra	3

Department ID	Department Name
1	Sales
2	Marketing
3	Finance

In this 3NF-compliant structure:

We've separated the Department information into a separate table.
Transitive dependencies are eliminated.

Why We Love 1NF

Data Integrity: 1NF ensures that each piece of data is atomic and indivisible. This prevents anomalies during data insertion, update, or deletion.
Efficient Queries: With 1NF, querying data becomes straightforward. There's no need to deal with complex nested structures or repeating groups.
Simplicity: 1NF simplifies data management. Each value has a clear place, making the database easier to understand and maintain.
Consistency: By adhering to 1NF, we achieve consistent data organization across tables, leading to better overall system reliability.

In summary, 1NF sets the groundwork for a well-organized, efficient, and reliable database. It's the first step toward creating a robust data structure.

In conclusion

Database normalization is not just a theoretical concept; it's a practical approach to designing robust databases that stand the test of time. By implementing the principles of 1NF, 2NF, and 3NF, we lay the groundwork for databases that are logical, scalable, and efficient. These normalization forms help us avoid data anomalies, streamline database operations, and ensure that our data remains consistent and reliable.

As we advance in the digital age, the importance of well-structured data cannot be overstated. Normalization is a key tool in our arsenal, enabling us to handle the ever-increasing volumes of data with grace and precision. Whether you're a database designer, developer, or administrator, embracing normalization is a step towards creating data systems that are not only functional but also future-proof.

In essence, normalization is the cornerstone of database excellence, and its disciplined application is a hallmark of quality in data management. It's a journey worth taking for anyone vested in the integrity and performance of their data systems.

Choosing Between Insert Functions and Raw Queries: A Practical Guide

Mohammad Alhraki — Wed, 13 Mar 2024 21:41:26 +0000

Introduction

When it comes to inserting data into a database, developers often face a crucial decision: should they use an insert function provided by an ORM (like Eloquent in Laravel) or directly execute a raw SQL query? In this blog post, we’ll explore the pros and cons of each approach and provide practical insights for making the right choice.

1. Understanding the Options

We’ll start by diving into the two main options available:

Insert Functions (E.g., Eloquent’s create())
- What they are.
- How they handle timestamps and other “magic.”
- Examples using Laravel’s Eloquent.
Raw SQL Queries (E.g., Query Builder’s insert())
- Writing custom SQL statements.
- Flexibility and control.
- When to use them.

2. Pros and Cons

Next, we’ll weigh the advantages and disadvantages of each approach:

Insert Functions:
- Pros:
  - Simplicity and readability.
  - Automatic handling of timestamps.
  - Object-oriented approach.
- Cons:
  - Limited flexibility.
  - Less control over the query.
Raw SQL Queries:
- Pros:
  - Fine-grained control.
  - Ability to handle complex scenarios.
  - Efficient for bulk inserts.
- Cons:
  - Manual query construction.
  - No automatic “magic.”

3. Bulk Inserts

Since you mentioned that your inserts will always be in an array, we’ll discuss bulk inserts in detail. How to efficiently insert multiple rows at once and optimize performance.

4. Best Practices

We’ll wrap up with some best practices:

Consistent naming conventions.
Parameterized queries to prevent SQL injection.
Testing on a local or test database before production.

Conclusion

By the end of this blog post, you’ll have a clear understanding of when to use insert functions and when to opt for raw queries. Armed with this knowledge, you’ll be better equipped to make informed decisions in your database operations.

Let’s explore the differences between creating an insert function and directly executing an insert query in the context of database operations.

Insert Function:
- An insert function is typically associated with an ORM (Object-Relational Mapping) framework like Eloquent in Laravel or similar tools in other languages.
- Here’s how they differ:
  - Eloquent’s create():
    - Purpose: Used to create a new record (row) in a database table.
    - Behavior:
      - Automatically fills in fields like created_at and updated_at (if defined in the model).
      - Abstracts away the actual SQL query construction.
      - Provides a more object-oriented approach.
    - Example (Laravel Eloquent):
```
Product::create([
    'name' => 'New Product',
    'price' => 100,
]);
```
  - Query Builder’s insert():
    - Purpose: Used to insert data directly into a table using raw SQL queries.
    - Behavior:
      - Requires you to construct the actual SQL query string.
      - Does not automatically handle timestamps or other Eloquent “magic.”
      - More flexible for complex scenarios.
    - Example (Laravel Query Builder):
```
DB::table('products')->insert([
    'name' => 'New Product',
    'price' => 100,
]);
```
Insert Query:
- When you execute an insert query, you directly write the SQL statement to insert data into the table.
- This approach is more low-level and gives you fine-grained control over the query.
- You can use it for both single-row inserts and bulk inserts (arrays).
Array Insert:
- If you’re always inserting multiple rows (an array of data), you can use the bulk insert feature.
- This is efficient because it reduces the number of database transactions.
- Both Eloquent and Query Builder allow you to insert multiple rows at once.

In summary:

Insert functions (like Eloquent’s create()) provide a higher-level abstraction and handle some aspects (like timestamps) for you.
Direct queries (like Query Builder’s insert()) give you more control but require manual SQL construction.
For array inserts, both approaches can handle bulk inserts efficiently.

For more details, refer to the Laravel Eloquent documentation 1 and the Laravel Daily article on Eloquent vs. Query Builder2.

more explanation

Certainly! Let’s explore the differences between creating an insert function and directly executing an insert query in the context of database operations.

Insert Function:
- An insert function is typically associated with an ORM (Object-Relational Mapping) framework like Eloquent in Laravel or similar tools in other languages.
- Here’s how they differ:
  - Eloquent’s create():
    - Purpose: Used to create a new record (row) in a database table.
    - Behavior:
      - Automatically fills in fields like created_at and updated_at (if defined in the model).
      - Abstracts away the actual SQL query construction.
      - Provides a more object-oriented approach.
    - Example (Laravel Eloquent):
```
Product::create([
    'name' => 'New Product',
    'price' => 100,
]);
```
  - Query Builder’s insert():
    - Purpose: Used to insert data directly into a table using raw SQL queries.
    - Behavior:
      - Requires you to construct the actual SQL query string.
      - Does not automatically handle timestamps or other Eloquent “magic.”
      - More flexible for complex scenarios.
    - Example (Laravel Query Builder):
```
DB::table('products')->insert([
    'name' => 'New Product',
    'price' => 100,
]);
```
Insert Query:
- When you execute an insert query, you directly write the SQL statement to insert data into the table.
- This approach is more low-level and gives you fine-grained control over the query.
- You can use it for both single-row inserts and bulk inserts (arrays).
Array Insert:
- If you’re always inserting multiple rows (an array of data), you can use the bulk insert feature.
- This is efficient because it reduces the number of database transactions.
- Both Eloquent and Query Builder allow you to insert multiple rows at once.

In summary:

Insert functions (like Eloquent’s create()) provide a higher-level abstraction and handle some aspects (like timestamps) for you.
Direct queries (like Query Builder’s insert()) give you more control but require manual SQL construction.
For array inserts, both approaches can handle bulk inserts efficiently.