Sitefinity to Tilda Migration: A Technical Guide

Sitefinity to Tilda Migration: A Technical Guide

Migrating from Sitefinity to Tilda means moving from a full-featured enterprise .NET CMS with deep API access, dynamic content types, and programmatic control over every object — to a block-based, no-code website builder designed for speed and visual design, not backend data management.

The hard truth up front: Tilda's API is read-only. You cannot create pages, blocks, or content programmatically via Tilda's API. Every page must be built manually in Tilda's visual editor or imported through narrow, format-specific pathways like the Feeds CSV import and the Product Catalog CSV import. This single constraint shapes the entire migration strategy.

Teams typically make this move to reduce .NET infrastructure costs, bypass long development cycles, and empower marketing teams with Tilda's visual editor and Zero Block. The trade-off is real: you gain design speed and publishing autonomy, but you lose programmatic content management, dynamic content types, role-based workflows, and the ability to automate page creation at scale.

This guide covers the full technical methodology: how to extract from Sitefinity's OData REST API, which Tilda import pathways actually exist, how to handle the content types that don't map cleanly, and what you will permanently lose.

The Core Architectural Conflict

Before writing extraction scripts, understand how fundamentally these data models differ.

Sitefinity relies on a strict, relational architecture built on ASP.NET. Content is structured into built-in modules (News, Blogs, Events) and Dynamic Modules created via the Module Builder. Pages are assembled using MVC widgets that query this structured data and render via Razor views. Content is separated from presentation. Sitefinity exposes all of this through OData REST endpoints; its GraphQL API provides read-only access to content items. (progress.com)

Tilda operates on a block-based, presentation-first model. A page is a static stack of block configurations. Content and presentation are tightly coupled. Tilda offers two structured data modules — Feeds (for blogs and news) and Catalog (for e-commerce products) — plus a newer Custom CMS Feeds feature with limited field types (text, image, gallery, video, HTML). Beyond those, there is no data modeling layer.

This structural mismatch—moving from a relational CMS to a block-based canvas—is a common hurdle in modern migrations, similar to the challenges of moving from SharePoint to Notion. Because you cannot programmatically create Tilda pages, your migration strategy splits into two tracks:

• Automated ingestion: Mapping Sitefinity structured content (Blogs, News, Dynamic Modules, Products) to Tilda Feeds and Tilda Catalog via CSV.
• Manual rebuild: Reconstructing static landing pages, homepages, and complex layouts using Tilda's visual editor.

Data Mapping: What Transfers and What Doesn't

Before extracting anything, get a clear picture of what Sitefinity objects exist and where they can land in Tilda.

What You Lose Permanently

• Dynamic content types — Sitefinity lets you define custom content types with arbitrary fields via the Module Builder. Tilda's Custom CMS Feeds offer five field types (text, image, gallery, video, HTML), which do not approach Sitefinity's Dynamic Module capability.
• Personalization — Sitefinity's personalization engine (showing different content to different user segments based on behavior or profile attributes) has no equivalent in Tilda.
• Workflow and approval chains — Tilda has no content approval system. There is no draft routing, reviewer assignment, or publish gating.
• Granular permissions — Sitefinity offers field-level role-based access control. Tilda has basic collaborator roles (owner, editor), but you cannot restrict a user to editing specific fields within a specific feed.
• Related data — Sitefinity's related data fields (one-to-one, one-to-many content relations) have no structural equivalent in Tilda. All relational data must be flattened into plain text or tags during transformation.
• Version history — Sitefinity maintains full content version history with rollback. Tilda's version control is limited to page-level backups, not granular data-level rollbacks.
• Multi-site management — Tilda supports up to 5 websites on a Business plan, but has no centralized multisite management dashboard equivalent to Sitefinity's multisite architecture.

Step 1: Extract Content from Sitefinity via OData API

Sitefinity exposes all content types — built-in and custom — through OData REST endpoints. This is your primary extraction path. Direct SQL queries against sf_news_items or sf_dynamic_content tables are possible but require complex joins to resolve publication status, versioning, and localized content. The OData API (available in Sitefinity 10+) is safer and more reliable for extraction.

API Authentication

Sitefinity's OData services require authentication. For migration scripts, use an API key configured in the Web Services module or an OAuth2 Bearer token:

curl -H "Authorization: Bearer <api-key>" \
  "https://your-sitefinity.com/api/default/newsitems?$filter=Status%20eq%20%27Published%27&$top=50&$skip=0&$orderby=PublicationDate%20desc"

Key Endpoints

A practical export job usually needs four datasets: a URL inventory and navigation tree, per-page layout and SEO metadata, structured content collections (news, blogs, custom module items), and a media inventory with current URLs and alt text. (progress.com)

Pagination

Sitefinity's OData services have a default page size of 50 items per query. You can configure this in Administration → Settings → Advanced → WebServices, but for extraction scripts, paginating with $top and $skip is standard:

import requests
 
def extract_all_items(base_url, entity, headers):
    items = []
    skip = 0
    page_size = 50
    while True:
        url = f"{base_url}/api/default/{entity}?$top={page_size}&$skip={skip}&$filter=Status eq 'Published'&$orderby=PublicationDate desc"
        resp = requests.get(url, headers=headers)
        data = resp.json()
        batch = data.get("value", [])
        if not batch:
            break
        items.extend(batch)
        skip += page_size
    return items

Sitefinity Dynamic Module Field Types and Tilda Mapping

Sitefinity's Module Builder supports the following field types in Dynamic Modules: Short text, Long text, Multiple choice, Yes/No, Currency, Number, Date and time, Related data (relational), Related media, Classification (taxonomy), Address, and Guid. When mapping to Tilda's Custom CMS Feeds, the translation is lossy by design:

Any Sitefinity Dynamic Module field that stores relational references — related items, related media, classification taxonomies — must be resolved and flattened to plain text or URL references before CSV generation. There is no foreign key concept in Tilda Feeds.

Extracting Rich Content Fields

Sitefinity stores rich text content (blog post bodies, news content) as HTML in the Content field. This HTML may contain:

• Internal links referencing Sitefinity URL patterns (e.g., /news/sample-news-item)
• Image references pointing to Sitefinity's media library (/images/default-source/...)
• Embedded widgets, content blocks, and proprietary Sitefinity tags (like sfref)
• Inline styles and .NET-specific HTML attributes

All of this must be processed during transformation. Sitefinity's rich text editor often outputs complex HTML that Tilda Feeds will break on or render poorly.

Extracting Media

Sitefinity stores media in structured libraries with metadata (alt text, descriptions, categories). Use the Images and Documents endpoints to list all items and download their binary content:

images = extract_all_items(base_url, "images", headers)
 
for img in images:
    file_url = f"{base_url}{img['Url']}"
    # Download and save locally for re-upload to external hosting

Sitefinity stores images either in the database as binary blobs or in an external provider (like Azure Blob Storage or AWS S3). Tilda's CSV importers require publicly accessible URLs to fetch images during ingestion. If your Sitefinity instance is behind a firewall or images require authentication, Tilda will fail to import them.

Best practice: Download all required images from Sitefinity, upload them to a temporary public bucket (AWS S3, Cloudflare R2), and map the new URLs to your content payload before generating CSVs.

Step 2: Transform Content for Tilda's Import Formats

Tilda has exactly two programmatic import pathways:

1. Feeds CSV Import — For blog posts, news items, and content that maps to Tilda's Feeds structure.
2. Product Catalog CSV Import — For e-commerce product data. The catalog CSV uses a semicolon separator and the import file limit is 50 MB. (help.tilda.cc)

Everything else is manual.

Tilda Feeds CSV: Required Schema

The Feeds CSV import expects specific column headers. The following schema reflects Tilda's documented field structure for standard feed posts:

Important encoding notes: Save the CSV as UTF-8 with BOM to prevent character encoding errors on Tilda's import parser. Use comma as the delimiter for Feeds CSV (semicolon is used for the Catalog CSV — they are not interchangeable). If a tag value references a category that does not exist in the feed, Tilda will create an uncategorized post rather than failing.

A minimal valid Feeds CSV looks like this:

title,description,text,date,image,tag,alias
"Q3 Product Update","Summary of Q3 changes","<p>This quarter we shipped...</p>","2024-09-15 09:00","https://cdn.example.com/images/q3-update.jpg","Product News","q3-product-update"
"Team Expansion","We hired 10 engineers","<p>Our team grew significantly...</p>","2024-10-01 10:00","https://cdn.example.com/images/team.jpg","Company News","team-expansion-2024"

Each Tilda feed holds a maximum of 5,000 posts. A project supports a maximum of 20 feeds. Feed posts do not count against Tilda's 1,000-page-per-project limit. (help.tilda.cc)

Choosing Between Tilda Feeds and Custom CMS Feeds

This is a content routing decision that must be made before CSV generation:

Custom CMS Feeds require you to define the field schema in Tilda's UI before importing. CSV column headers must exactly match the field names you define. This is not documented as a visual UI feature — it must be configured per-feed before any CSV upload is attempted.

Preparing Blog/News Content for Feeds CSV

Field mapping for blog/news:

HTML Sanitization:

Sitefinity's rich text content needs aggressive cleaning before it will render in Tilda Feeds. Tilda supports basic HTML (paragraphs, bold, links, lists) but will break on complex <div> structures, inline CSS, or Sitefinity-specific widget placeholders:

import csv
import re
 
def clean_html_for_tilda(html, image_map):
    """Strip Sitefinity-specific markup and rewrite image URLs."""
    # Remove Sitefinity widget placeholders
    html = re.sub(r'<div[^>]*sf_colsIn[^>]*>.*?</div>', '', html, flags=re.DOTALL)
    # Remove sfref tags (Sitefinity internal link tokens)
    html = re.sub(r'\[sfref[^\]]*\]', '', html)
    # Strip inline styles
    html = re.sub(r' style="[^"]*"', '', html)
    # Rewrite image URLs using the mapping from downloaded media
    for old_url, new_url in image_map.items():
        html = html.replace(old_url, new_url)
    return html
 
def generate_feeds_csv(posts, image_map, output_path):
    with open(output_path, 'w', newline='', encoding='utf-8-sig') as f:  # utf-8-sig adds BOM
        writer = csv.writer(f)
        writer.writerow(['title', 'description', 'text', 'date', 'image', 'tag', 'alias'])
        for post in posts:
            writer.writerow([
                post['Title'],
                post.get('Summary', ''),
                clean_html_for_tilda(post['Content'], image_map),
                post['PublicationDate'][:16].replace('T', ' '),  # Format to YYYY-MM-DD HH:MM
                image_map.get(post.get('featuredImageUrl', ''), ''),
                ', '.join(post.get('Tags', [])),
                post.get('UrlName', '')
            ])

Mapping Products to Tilda Catalog

If your Sitefinity site uses Ecommerce or a custom Dynamic Module for a product catalog, map it to the Tilda Catalog. The Catalog CSV uses a semicolon delimiter (not comma). Key columns:

• SKU — Unique identifier.
• Title — Product name.
• Price — Numeric value (no currency symbols).
• Text — Product description.
• Photo — Public URL of the product image.
• Section — Maps to Sitefinity Taxonomies/Categories.

Step 3: Import into Tilda

With sanitized CSVs ready, the ingestion process runs through Tilda's UI:

1. Navigate to Site Settings → Feeds (or Catalog).
2. Create a new Feed.
3. For Custom CMS Feeds: define the field schema first, ensuring field names match your CSV column headers exactly.
4. Select Import → Upload CSV.
5. Map your CSV columns to Tilda's native fields.

Tilda will process the file, download images from the URLs provided, and populate the feed. Always run a test import with 5–10 rows first and inspect each post in the Feeds editor before uploading the full dataset.

For editorial content, decide early between normal pages with Index blocks and Feeds. Index blocks work better when posts are visually unique and you want each page fully designed. Feeds work better when posts follow a consistent structure and volume is higher. That decision affects how much Sitefinity page-level design you can preserve. (help.tilda.cc)

Step 4: Rebuild Pages Manually in Tilda

This is the labor-intensive phase. Every Sitefinity page — landing pages, service pages, about pages, contact pages — must be manually recreated in Tilda's block-based editor.

Page Type Routing Decision

Before touching Tilda's editor, classify each Sitefinity page into one of four routing categories:

Strategy for Page Reconstruction

Inventory first. Export a full list of Sitefinity pages with their URLs, titles, and template assignments via the OData Pages endpoint. Prioritize by traffic using your analytics data. Output a spreadsheet with these columns: Page Title, Original URL, Target Tilda URL, Template Assignment, Routing Category, Status (To Rebuild / Deprecated / Redirect).

Build reusable templates before touching bulk content. Create shared headers, footers, menus, page templates, blog card patterns, CTA blocks, and form styles first. Tilda supports reusable page templates and this approach prevents inconsistency across dozens of rebuilt pages.

Map page layouts to Tilda blocks. Sitefinity uses page templates with widget zones. Tilda uses a flat block stack. For each Sitefinity page template, identify which Tilda blocks (from the 550+ block library) can replicate the layout. Document the template-to-block mapping in a shared reference before any page rebuilding begins.

Use Zero Block for complex layouts. Tilda's Zero Block is a freeform design canvas with pixel-level control and a 12-column grid. Reserve it for high-fidelity marketing pages that don't map to standard blocks — it is time-intensive to build and should not be the default approach.

Embed custom HTML where needed. Tilda allows embedding raw HTML, CSS, and JavaScript via an HTML embed block. For Sitefinity content that doesn't fit Tilda's block model, drop cleaned HTML directly into an embed block. This is a pragmatic fallback for complex content that would take too long to rebuild block-by-block.

Page Limit Constraints

Tilda limits all plans to 1,000 pages per project. If your Sitefinity site has more than 1,000 pages, you need to either consolidate content, split across multiple Tilda projects, or route high-volume content through Feeds (which does not count against the page limit).

Step 5: Handle Media and Image Assets

Sitefinity stores media in structured libraries with metadata (alt text, descriptions, categories). Tilda handles images per-block — there is no centralized media library.

1. Download all Sitefinity media via OData Images/Documents endpoints.
2. Organize files locally by original library structure.
3. For Feeds/Catalog posts, host images on an external CDN (Cloudflare R2, AWS S3) and reference the URLs in your CSV import.
4. For manually-built pages, upload images directly through Tilda's block editor.
5. Preserve alt text — Sitefinity stores alt text as image metadata in the AlternativeText field on the OData Images endpoint; you must manually re-apply it in Tilda's image settings per block.

Step 6: SEO, URL Mapping, and 301 Redirects

Sitefinity often generates deep, hierarchical URLs based on taxonomy and date (e.g., /news/press-releases/2023/10/01/company-announces-new-product). Tilda's URL structure is generally flatter — feed posts take the format /feed-name/post-slug. URL changes are inevitable in this migration.

Every old Sitefinity URL must have a 301 redirect to its new Tilda equivalent. Without this, all accumulated search authority for those URLs is lost.

Build the redirect map from your Sitefinity OData export:

redirect_map = {}
for post in sitefinity_posts:
    old_url = f"/news/{post['UrlName']}"
    new_url = f"/blog/{post['UrlName']}"  # Adjust to Tilda Feeds URL pattern
    redirect_map[old_url] = new_url
 
# Export as CSV for implementation
import csv
with open('redirect_map.csv', 'w', newline='') as f:
    writer = csv.writer(f)
    writer.writerow(['old_url', 'new_url', 'status_code'])
    for old, new in redirect_map.items():
        writer.writerow([old, new, 301])

Tilda's redirect behavior has important constraints. Tilda supports 301 redirects, but they work only within the same domain and only from non-existent pages. To redirect from one existing Tilda page to another, you need to use a redirect block (T223). For old-domain-to-new-domain migrations, Tilda does not offer automated redirect tooling — you need registrar forwarding or server-level rules. (help.tilda.cc)

Tilda auto-generates robots.txt and sitemap.xml and includes a broken-link checker in site SEO settings. Use the broken-link checker as a post-launch verification step, but do not rely on it as your only QA mechanism.

Pre-Launch QA Checklist

Before going live, verify each of the following explicitly:

1. Redirects verified — Crawl all old Sitefinity URLs and confirm each returns HTTP 301 to the correct new URL. Use Screaming Frog or a curl-based script against the redirect map CSV.
2. Internal links rewritten — Every internal link in every migrated post and page references the new Tilda URL structure. Grep the Feeds CSV output for old domain patterns before import.
3. Alt text applied — Spot-check at least 10% of migrated images in Tilda's block editor to confirm alt text was manually re-applied.
4. Forms tested — Submit each rebuilt form and confirm the submission is delivered to the correct destination (email, webhook, CRM).
5. Analytics firing — Confirm Google Analytics / GTM is receiving pageview events on both feed posts and rebuilt pages before cutover.
6. Sitemap submitted — Submit the Tilda-generated sitemap.xml to Google Search Console immediately after DNS cutover.
7. Feed posts indexed correctly — Check that feed post URLs follow the expected pattern and are included in the sitemap.
8. Page limit headroom — Confirm total Tilda page count (excluding Feeds) is under 1,000.
9. Image load verification — Confirm externally-hosted images (for Feeds CSV imports) are loading via public URLs and have not expired or moved.
10. Broken link scan — Run Tilda's built-in broken-link checker and resolve all reported issues before DNS cutover.

Step 7: Rebuild Forms, Integrations, and Analytics

Forms

Sitefinity forms write data directly to a SQL database with field validation, workflow routing, and persistent storage. Tilda forms are simpler — they act as routers, forwarding submissions to external services.

For each Sitefinity form:

1. Document all fields, validation rules, and submission destinations.
2. Recreate the form using Tilda's form blocks.
3. Configure Tilda's integrations: email, Google Sheets, webhooks, CRM connectors (HubSpot, Pipedrive, Salesforce), Telegram, or Slack.
4. Test submission routing before going live.

If your Sitefinity forms triggered complex backend C# logic (e.g., validating a serial number against an external ERP before allowing submission), offload this logic to a serverless function (AWS Lambda, Azure Functions) and point the Tilda form webhook there.

Tilda webhooks deliver data via POST, require HTTPS, and the receiving script must respond within five seconds or the submission is retried twice. (help.tilda.cc)

Historical Sitefinity form submissions cannot be migrated to Tilda. Export them from Sitefinity to CSV and archive them separately before cutover.

Analytics

Tilda natively supports Google Analytics and Google Tag Manager integration. Configure these in Site Settings before launch to avoid tracking gaps. Confirm that GA/GTM is receiving pageview events on both feed posts and rebuilt pages before DNS cutover.

Third-Party Integrations

Sitefinity's Integration Hub and custom .NET code may power integrations with no direct Tilda equivalent. Audit every active integration and determine whether Tilda's built-in connectors, Zapier, or webhook-based flows can replace them.

Edge Cases That Break Timelines

These constraints tend to surface late in migration projects:

• Multilingual sites: Tilda's standard language switchers support up to three languages with built-in features. For sites with four or more language versions, Tilda's own documentation points to custom navigation patterns or third-party translation services like Weglot. Operationally, this means: extract each Sitefinity language version separately via OData (using the $filter=Language eq 'de' parameter or equivalent locale filter), generate a separate Feeds CSV per language, and create separate feeds per language in Tilda. You cannot duplicate an entire Tilda website — only individual pages — which significantly increases rebuild labor for multilingual rollouts. (tilda.cc)
• Membership migrations: Tilda's member import is capped at 100 users per day. A 5,000-member migration takes 50 days at that rate. Plan cutover timing accordingly; you cannot batch-accelerate this. (tilda.cc)
• Large blogs: Each Tilda feed is capped at 5,000 posts, and a project can hold up to 20 feeds (100,000 posts maximum across all feeds). If your Sitefinity blog exceeds 5,000 posts in a single category or section, you need to split content across multiple feeds and reconcile the URL structure.
• Internal link rewriting: Every internal link in every piece of migrated content references Sitefinity's URL patterns. Rewrite these systematically in the transformation script before generating CSVs — do not attempt to fix them manually post-import.
• Alt text migration: Sitefinity stores alt text in the AlternativeText field on the Images OData endpoint. Export this field alongside the image URL in your media inventory. In Tilda, it is a per-block setting that must be manually configured — there is no bulk alt text import.
• Hybrid export requirement: If you use Tilda's API export feature to serve pages on your own infrastructure, Tilda requires a "Made on Tilda" identifier with a link on every exported page. Review legal and brand implications before committing to this path. (help.tilda.cc)

Tilda API: What It Actually Does

The Tilda API is an export/sync API, not an import API. It provides read-only endpoints for retrieving project and page data — useful for syncing Tilda content to an external server, not for pushing content into Tilda.

Available endpoints:

• GET /v1/getprojectslist — List all projects
• GET /v1/getprojectinfo — Project metadata
• GET /v1/getpageslist — List pages in a project
• GET /v1/getpage — Page body HTML
• GET /v1/getpagefull — Full page HTML
• GET /v1/getpageexport — Page HTML for export with asset references
• GET /v1/getpagefullexport — Full page HTML for export

The API requires a Tilda Business plan and is rate-limited to 150 requests per hour. It is useful for post-migration verification — you can pull exported HTML to confirm content was correctly built — but it plays no role in the actual data import process. (If you are evaluating Tilda against other visual builders, note that restrictive export APIs are common in this space; see our guide on Webflow's export methods and API limits for comparison).

When This Migration Makes Sense (and When It Doesn't)

Good fit:

• Marketing-focused sites with fewer than 200 pages
• Teams that want non-technical staff to manage and publish content independently
• Organizations looking to eliminate .NET hosting and licensing costs
• Sites where visual design iteration speed matters more than content modeling flexibility

Poor fit:

• Sites with more than 1,000 pages and complex content hierarchies
• Applications relying on Sitefinity's Dynamic Modules for structured relational data
• Teams that need programmatic content management or CI/CD pipelines for content
• Multi-language sites with more than three language versions and complex translation workflows
• Sites with large membership bases that cannot tolerate a 100-user/day import ceiling
• Organizations requiring content approval workflows or field-level access control

Progress documents Sitefinity as a CMS/DXP with decoupled rendering, page APIs, REST/OData, and GraphQL support. Tilda documents itself as a visual website builder centered on blocks, feeds, forms, and lightweight commerce. If your Sitefinity implementation behaves more like a composable content application than a marketing site, Tilda should not replace the whole architecture.

Migration Timeline Estimates

The bottleneck is always the manual page rebuild phase. The extraction and transformation phases can be scripted and accelerated; the page rebuild phase scales linearly with page count and layout complexity.

Common Pitfalls

• Assuming Tilda has a write API. It doesn't. Plan for manual work from day one.
• Ignoring the 1,000-page limit. Route high-volume content (blog, news) through Feeds to stay under the cap.
• Using the wrong CSV delimiter. Feeds CSV uses commas; Catalog CSV uses semicolons. Mixing them causes silent import failures.
• Incorrect date format in Feeds CSV. Tilda expects YYYY-MM-DD HH:MM. Any other format defaults silently to the import date, corrupting publication order.
• Missing CSV encoding. Save Feeds CSVs as UTF-8 with BOM (utf-8-sig in Python). Without this, non-ASCII characters corrupt on import.
• Losing internal link structure. Every internal link in every piece of content needs rewriting before CSV generation.
• Skipping alt text. Export AlternativeText from Sitefinity's Images endpoint and track it in your media inventory for manual re-application in Tilda.
• Forgetting multilingual content. Each Sitefinity language version is a separate content item. Tilda requires separate feeds and separate page rebuilds per language.
• Not archiving Sitefinity data. Keep a full OData export and ZIP backup before the Sitefinity license lapses — you lose access to the data API at that point.
• Sloppy asset handling. Maintain a formal asset map (Sitefinity URL → CDN URL) as a CSV and use it programmatically in all transformation scripts. Ad hoc uploads produce broken image references that are difficult to audit at scale.

Related Migration Guides

For related technical content on navigating structural mismatches and API constraints, see our guides on SharePoint to Notion migration and how to export data from Webflow.