Going To for Plans Already in Motion

By the end of this lesson, you will be able to...

• Use going to to describe a technical plan that already exists.

• Compare going to with will when writing a status update.

• Explain the trade-off in a planned change without making the plan sound accidental.

Idea in one sentence: In technical English, going to often says, "This is already the plan, and the team is moving toward it."

Core Insight

In the previous lesson, you used will for decisions and predictions:

We will roll back if errors keep rising.
The queue will keep growing if workers stay paused.

Those sentences answer a next-step question from the current situation. The team sees evidence, then decides or predicts what happens next.

Going to is different.

The central practice line for this lesson is:

We are going to split the migration into two steps.

This does not sound like a decision made in this exact second. It sounds like the plan already exists. Maybe the team discussed it in planning. Maybe the pull request is open. Maybe the deploy checklist has changed. The action has not happened yet, but the direction is already set.

That is the useful mental model:

will = decision or prediction from now
going to = plan already decided or already forming

The difference is small, but in engineering status it matters. A reader wants to know whether you are proposing a response, predicting a result, or reporting a plan that is already in motion.

Compare:

We will split the migration if replication lag increases.
We are going to split the migration into two steps.

The first sentence is conditional. It says what the team will do if a signal gets worse.

The second sentence reports the plan. It says the team has already chosen a safer migration shape.

The Small Situation

Imagine a team preparing a database migration.

The first plan was simple:

Run one migration.
Move all existing records.
Deploy the new worker.
Monitor the queue.

Then the team tests the migration in staging. The import is slower than expected, and the worker creates more retry traffic than expected.

Nobody is in panic mode. This is not yet an incident. The team has time to adjust the plan before production.

In the planning channel, someone writes:

We are going to split the migration into two steps.

That sentence gives the reader a useful signal:

• the decision is already made
• the work is still future
• the team is moving toward that future work
• the plan has a reason

A weaker update would be:

Maybe we split the migration.

That sounds uncertain. It may be fine during brainstorming, but it is weak as a status update after the team has chosen a plan.

Another weak update is:

We will split the migration into two steps.

This is not always wrong. Native speakers use will in many future sentences. But in this scenario, going to gives a better status signal. It tells the reader that the plan already exists, not that the team is deciding right now.

Plain to Precise

A literal translation can make the sentence heavier than it needs to be:

We are going to make a division of the migration in two steps.

The sentence is understandable, but the noun phrase make a division of feels unnatural in a technical update.

Prefer the direct verb:

We are going to split the migration into two steps.

The technical object is visible: the migration.

The action is visible: split.

The structure is visible: into two steps.

You can use the same shape with other engineering plans:

We are going to move the worker to a smaller batch size.
We are going to keep the feature flag disabled until Monday.
We are going to add a retry limit before enabling the new route.

Each sentence says, "This is already the plan." The reader does not have to guess whether the team is still discussing it.

Plain meaning:

We have chosen a future action.

In this scenario:

The migration is not split yet, but the team has decided to split it.

Technical name:

Use `be going to` for a plan already decided or clearly forming.

The Naive Idea

The naive idea is:

Use `going to` whenever the action is in the future.

That works sometimes, but it creates confusion in technical writing.

If every future sentence uses going to, the reader may think every future event is already planned.

Compare these:

We are going to restart the worker if errors keep rising.
We will restart the worker if errors keep rising.

The second sentence is usually cleaner for a conditional response. The team is not saying the restart is already planned no matter what. The restart depends on a signal.

Now compare:

We will split the migration into two steps.
We are going to split the migration into two steps.

Both can be grammatical. But the second one is stronger as a planning update. It sounds like the split is already the chosen path.

So the practical rule is:

Use going to when the important message is that the plan already exists.

Use will when the important message is a decision made now, a conditional response, or a prediction.

A Worked Planning Update

Let us build a planning update from rough notes.

Raw notes:

staging import slow
worker retries more than expected
single migration too risky
team chose two phases
phase 1 copies old records
phase 2 enables new worker
trade-off: slower rollout, safer rollback

First, report the evidence:

The staging import has been slower than expected.

This uses present perfect because the evidence exists now.

Next, report the risk:

A single migration would make rollback harder.

This is not the main grammar pattern today, but it is a useful technical sentence. It explains why the plan changed.

Now report the plan:

We are going to split the migration into two steps.

This is the going to sentence. It tells the reader the team has already chosen the plan.

Then make the plan inspectable:

First, we are going to copy the old records. Then we are going to enable the new worker.

Finally, name the trade-off:

This will make the rollout slower, but it will give us a safer rollback path.

Now the complete update is:

The staging import has been slower than expected. A single migration would make rollback harder, so we are going to split the migration into two steps. First, we are going to copy the old records. Then we are going to enable the new worker. This will make the rollout slower, but it will give us a safer rollback path.

Notice the path:

The naive update only says:

We will change the migration.

That is too small. It hides the evidence, the plan shape, and the trade-off. The worked update gives the reader enough context to trust the plan.

Going To vs Will

Use this question:

Is the team deciding now, or describing an existing plan?

Decision now:

Errors are still rising, so we will roll back.

Existing plan:

We are going to split the migration into two steps.

Conditional response:

We will pause the migration if replication lag increases.

Existing plan with reason:

Replication lag was high in staging, so we are going to run the migration in smaller batches.

Prediction:

The queue will drain slowly if we keep intake open.

Plan:

We are going to keep intake closed during the first batch.

The difference is not about grammar perfection. It is about reader expectations. Going to makes the future action feel more planned. Will makes it feel more like a decision, promise, condition, or prediction.

You can often recognize a real going to situation by the evidence around it:

The ticket is already assigned.
The pull request is already open.
The team has already chosen the safer path.
The checklist already includes the new step.

Those signals do not mean the work is finished. They mean the plan has shape. In that situation, going to is useful because it points to the current fact behind the future action: the team is already moving in that direction.

Without those signals, be more careful:

We may split the migration.
We are considering splitting the migration.
We will split the migration if the staging test fails again.

These alternatives keep uncertainty visible.

Check: Which sentence sounds more like a plan already chosen?

A. We will split the migration if replication lag increases.
B. We are going to split the migration into two steps.

Think first, then reveal.

Answer: B. Sentence A depends on a future condition. Sentence B reports the plan as already chosen.

Going To vs Present Continuous

The next lesson focuses on present continuous for scheduled engineering work:

We are deploying the new worker tomorrow.

That sentence sounds arranged. It often includes a time marker:

tomorrow
at 22:00 UTC
next Monday
during the maintenance window

Going to is a little different. It focuses less on the calendar and more on the plan:

We are going to deploy the new worker after the migration.

Both forms can be natural. The difference is what you want the reader to notice.

If the important detail is the plan:

We are going to split the migration into two steps.

If the important detail is the arranged schedule:

We are deploying the new worker tomorrow.

Here is a small way to choose:

This table is not a law. Real English is flexible. It is a status-writing tool. When you know what signal the reader needs, the tense choice becomes much easier.

Do not worry if this feels close. It is close. The track separates these lessons so you can practice one signal at a time.

Trade-offs and Limits

Going to makes a plan sound real. That is useful, but it also has a cost.

If the plan is not actually decided, going to can sound too confident.

Too strong:

We are going to replace the queue system.

If the team is only discussing options, write:

We are considering replacing the queue system.

Or:

We may replace the queue system if the current retry limit is not enough.

Another limit: going to does not prove the plan is safe. It only says the plan exists.

Weak:

We are going to split the migration, so it is safe.

Better:

We are going to split the migration into two steps. This gives us a safer rollback path, but it makes the rollout slower.

That sentence gives the plan and the trade-off. It does not pretend the plan has no cost.

You can see the boundary when a reader asks:

Is this already approved, or only a proposal?

If the answer is "only a proposal", avoid going to. Use may, might, could, are considering, or are evaluating.

Common Confusions

Confusion: Going to Means the Action Is Happening Now

Why it is tempting:

We are going to... contains are, so it looks like present continuous.

Better model:

The plan exists now. The action happens later.

We are going to split the migration into two steps.

The split has not happened yet. The current fact is the plan.

Confusion: Going to and Will Are Always Interchangeable

Why it is tempting:

Both forms can point to the future.

Better model:

Choose the form that gives the reader the right signal.

We will roll back if errors keep rising.

This is a conditional decision.

We are going to split the migration into two steps.

This is a plan already chosen.

Confusion: A Plan Sentence Does Not Need Evidence

Why it is tempting:

The plan may feel obvious to the writer.

Better model:

Readers often need the reason, especially when the plan changes production risk.

The staging import has been slower than expected, so we are going to split the migration into two steps.

Now the plan has visible evidence.

Check Your Understanding

Check: A teammate writes, We are going to restart the worker if errors keep rising. What is slightly off?

Think first, then reveal.

Answer: The sentence uses going to for a conditional response. We will restart the worker if errors keep rising is usually clearer, because the restart depends on a future signal.

Check: A team has already approved a safer migration plan. Which sentence fits best?

A. We are going to split the migration into two steps.
B. The migration will have been split.
C. We split maybe the migration later.

Think first, then reveal.

Answer: A. It reports an existing plan in natural technical English.

Practice

Start with this rough status:

The staging import has been slower than expected. A single migration would make rollback harder.

Add a going to plan:

We are going to split the migration into two steps.

Now make the plan more specific:

We are going to copy old records first.
We are going to enable the new worker after the copy finishes.
We are going to keep the feature flag disabled during the first batch.

Now add the trade-off:

This will make the rollout slower, but it will give us a safer rollback path.

Try the same pattern with another technical object:

The cache warmup took longer than expected, so we are going to deploy the cache change separately.
The retry rate was high in staging, so we are going to add a retry limit before enabling the route.
The new index increased write latency, so we are going to test it with a smaller tenant first.

The goal is not to make every sentence long. The goal is to make the plan, evidence, and trade-off visible.

Daily Practice Lines

Repeat these three lines during the day:

We are going to split the migration into two steps.
We will roll back if errors keep rising.
The staging import has been slower than expected.

The first line is the new pattern.

The second line reviews will from lesson 012.

The third line reviews evidence language from earlier lessons, because a plan is easier to trust when the evidence is visible.

Resources

• [ARTICLE] Cambridge Dictionary Grammar: Be going to - Use it to compare planned future actions with other future forms.
• [ARTICLE] Cambridge Dictionary Grammar: Future forms - Use it as a reference when will, going to, and present continuous feel close.
• [ARTICLE] Microsoft Writing Style Guide - Use it as a reminder to keep planning updates concrete and reader-centered.

Key Takeaways

• Use going to when the team already has a plan: We are going to split the migration into two steps.
• Use will when the next step is a decision, prediction, or conditional response: We will roll back if errors keep rising.
• Use present continuous with a time marker when the main signal is an arranged schedule: We are deploying the new worker tomorrow.
• A plan still needs limits: name the trade-off when the plan changes cost, risk, or timing.