If you upgrade from Umbraco 13 to Umbraco 17 and suddenly see Block List / Block Grid items marked as Draft (and non-default languages show empty content), you’re very likely hitting a configuration mismatch.
This post explains:
how the issue occurs
what the issue is creating in your content
what you see in Umbraco 17
how to fix it before upgrading (in Umbraco 13) using SQL
how to validate the fix
This happens specifically when:
A Content Type is an Element Type
That Element Type is configured as Vary by Culture
That Element Type is used inside Block List / Block Grid (as the block’s “Document Type behind the block”)
In Umbraco 13, that “vary by culture” setting on Element Types effectively didn’t behave the same way as later versions, so you could end up with a setup that “worked” without being truly consistent.
From Umbraco v15 and up, Umbraco supports block-level variance (shared across cultures vs per-culture values), and Umbraco 17 is stricter about what is actually published per culture.
So the upgrade exposes this: your database contains values, but per-culture publishing state isn’t what Umbraco 17 expects.
After the upgrade, Umbraco 17 treats those element values as culture-variant block data. If a specific culture doesn’t have a published version of that element/block, Umbraco will consider it “exists, but only as draft for that culture”.
Result:
Default culture might still render (sometimes even while UI says “Draft”)
Other cultures can show 0 content for those blocks
Editors are forced to “create”/publish the missing culture versions per block item (a lot of manual work)
Typical symptoms in the backoffice after upgrading:
In Block Grid / Block List, many items show as Draft (even when you know content exists)
Switching to another culture shows empty block content
Editing the block often looks like you need to create/publish that culture variant for the element type
This matches what is described in the forum thread: items show as draft for cultures and other languages appear empty.
The simplest and most reliable fix is to ensure Element Types are NOT culture-variant before you upgrade.
You can do this manually in Umbraco 13 (by updating each element type), but that’s slow and error-prone if you have many block element types.
Run this in Umbraco 13’s database before upgrading:
BEGIN TRANSACTION;
-- Update variations from 1 to 0 for element types
UPDATE [dbo].[cmsContentType]
SET variations = 0
WHERE isElement = 1
AND variations = 1;
COMMIT;
-- If something looks wrong, use:
-- ROLLBACK;
What this does:
Finds all Element Types (isElement = 1) that are marked as Vary by Culture (variations = 1)
Sets them to invariant (variations = 0)
This aligns the configuration with what Umbraco 13 effectively behaved like for these element types, and prevents Umbraco 17 from interpreting them as culture-variant block data.
Take a database backup first
Run on a staging copy first
If you use multiple databases/environments, apply it consistently
In the database, check there are no remaining element types with variations = 1:
SELECT id, alias, isElement, variations
FROM cmsContentType
WHERE isElement = 1 AND variations = 1;
Expect: 0 rows
In Settings -> Document Types:
Spot check a few block element types
Confirm “Vary by culture” is no longer enabled (or behaves as invariant)
Open content nodes that contain Block Grid / Block List
Switch between cultures
Confirm:
blocks no longer show unexpected Draft states
existing content shows up for non-default languages
you are not forced to manually “create/publish” culture variants for each block item
If those checks pass, the mismatch is resolved.
In Umbraco 13 you could configure element types as “Vary by culture” but it wouldn’t have the same effect as in Umbraco 17. In newer versions, that setting becomes meaningful for blocks and their culture-specific publishing states.
By normalizing element types to invariant before upgrading, you avoid Umbraco 17 treating existing block element data as “draft per culture”.