Error After Moving From Server To Server And Changing Url — this archived support thread from the APG vNext community covers a reported issue and its resolution.
Troubleshooting This Issue
- Set
customErrors mode="Off"inweb.configto expose the full error and stack trace. - Check Windows Event Viewer → Application log for ASP.NET exceptions.
- Review Admin Panel → Logs → Error Log for timestamped application errors.
- Restart the IIS Application Pool to clear stale state.
- Verify the database connection string and run any pending upgrade SQL scripts.
Related Resources
Errors After Moving APG vNext to a New Server or Changing the URL
Moving APG vNext to a new server or changing the site URL (e.g. from http:// to https://, or from a subdomain to a root domain) requires updating several settings beyond just the connection string. Missing these updates causes broken links, incorrect canonical URLs, email links pointing to the old domain, and licence validation failures.
Full Checklist for Server Move or URL Change
1. web.config Updates
<add key="APG.SiteUrl" value="https://newdomain.com" />
<add key="APG.LicenseKey" value="NEW-SERVER-KEY" />
<add key="APG.CookieDomain" value=".newdomain.com" />2. Database Updates
-- Update stored absolute URLs in the database:
UPDATE apg_Settings
SET SettingValue = 'https://newdomain.com/community'
WHERE SettingKey = 'SiteUrl';
-- Update email templates that reference the old URL:
UPDATE apg_EmailTemplates
SET TemplateBody = REPLACE(TemplateBody,
'http://olddomain.com', 'https://newdomain.com');3. Set Up URL Redirects from Old Domain
<rule name="OldToNew" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="^olddomain\.com$" />
</conditions>
<action type="Redirect"
url="https://newdomain.com/{R:1}"
redirectType="Permanent" />
</rule>4. Purge CDN Cache
If using Cloudflare or another CDN, purge all cached content to ensure the new domain/HTTPS URLs are served.
Forms Authentication and Machine Key After Server Move
When moving APG vNext to a new server, the machineKey in web.config must be preserved exactly from the old server configuration. The machine key is used to encrypt and validate Forms Authentication cookies and CSRF tokens. If the machine key changes — which it does by default when deploying to a new server without explicit configuration — all existing login sessions are invalidated and users are logged out. For the best migration experience, explicitly configure a static machine key in web.config before the migration and use the same key on the new server:
<!-- Generate with: IIS Manager → Machine Key → Generate Keys -->
<machineKey
validationKey="[64-char-hex]"
decryptionKey="[48-char-hex]"
validation="SHA1"
decryption="AES" />SSL Certificate Configuration After URL Change
Changing from HTTP to HTTPS as part of a server move or URL change requires installing an SSL certificate on the new server. APG vNext has no direct involvement in SSL termination — it is handled by IIS. However, after switching to HTTPS, update all hardcoded HTTP URLs in the APG vNext database (email templates, embedded image URLs in posts, avatar URLs) to HTTPS to eliminate mixed content warnings that browsers show when an HTTPS page loads HTTP resources. The database URL update script handles email templates but not post content. Use a bulk search-and-replace on the post content table for the absolute domain switch:
-- Update post content (backup first):
UPDATE apg_Posts
SET PostBody = REPLACE(PostBody,
'http://olddomain.com', 'https://newdomain.com')
WHERE PostBody LIKE '%http://olddomain.com%';
PRINT 'Updated: ' + CAST(@@ROWCOUNT AS VARCHAR) + ' posts';DNS Propagation and Transition Period
During the transition period between old and new server, DNS TTL determines how long cached DNS records point clients to the old server IP. Lower the DNS TTL to 60 seconds (from 3600) at least 24 hours before the migration to ensure DNS changes propagate quickly. After the migration is complete and verified, restore the TTL to 3600 to reduce DNS lookup overhead. During the transition, both old and new servers may receive traffic — ensure the old server serves redirects to the new domain during this period to prevent SEO impact from duplicate content.
Validating Links After a URL Change
After changing the APG vNext site URL (e.g. HTTP to HTTPS, or domain rename), use a link checker tool to scan the forum for broken internal links in post content that still reference the old URL. Common link checker options include Screaming Frog SEO Spider, Xenu Link Sleuth, and the built-in site audit in Ahrefs or SEMrush. Run the link check against the new URL and filter for 4xx responses — these indicate posts that link to old URLs that now return errors or redirect loops. For posts with high traffic, fix the embedded links manually. For the general population of old posts, a database-level search-and-replace on the post content table is the most efficient approach to systematically update all embedded old-domain links in a single operation.
Updating Google Search Console and Analytics After URL Change
After changing the APG vNext site URL, update the Google Search Console property to add the new URL as a property and submit the updated sitemap. If the change was from HTTP to HTTPS, add both the HTTP and HTTPS versions as separate properties and verify that the HTTPS property is receiving the majority of impressions after the migration (HTTP impressions should drop to zero within 1-2 weeks as Google processes the 301 redirects). Update the Google Analytics property to use the new canonical URL so that traffic is correctly attributed. If using Google Analytics 4, update the Data Stream configuration with the new URL. Failure to update Analytics results in traffic being split between the old and new URL in reports, making it impossible to accurately measure the migration's impact on organic traffic.
Related Resources
Looking for more help? Browse the support forum or check the Knowledge Base.