To migrate from SharePoint 2007 to 2013 without using third party tools, you'll need to go via an intermediate SharePoint 2010 farm. You should be able to build one on a trial license however for the purposes of the work you're trying to perform.
You'll want to perform a trial run of the migration to ensure that you have all of the required steps in place before performing the final migration. Testing will be key as well, as you'll need feedback from all of the stakeholders to ensure that the migration will go as planned.
What you're trying to achieve is quite a long an involved job. The way I'd go about it is as follows:
Tidy up the 2007 farm first. Remove any unused solutions from the farm. Ensure that all pages are in 2007 mode and remove any page customisations that have been produced using SharePoint designer.
Let your users know that a migration is in the works. Prepare any required training that will need to be circulated.
Build a SharePoint 2010 farm. You'll need to be able to successfully migrate from 2007 to 2010 as the first step in the chain. Assume that this farm will be a throwaway farm as you may need to rebuild it several times if your initial migration from 2007 to 2010 doesn't go as planned. Aim to build this with PowerShell as you'll need to use PowerShell during the farm build to allow you to specify the database names in some cases. Building the entire farm with PowerShell will, in the long run, also be easier as it guarantees the same farm configuration each time. you can either build this farm on the original domain, or on the new one. Ensure that you have a new SQL Server for this farm to work against.
Install any required customisations to the new farm. Note that not all customisations will be supported by 2010 (let alone 2013!), so adding them to the farm and testing them is critical. If there are new versions of any customisations, use those instead. You'll want to check whether the customisations have 2013 versions as well. the key here is that the simpler, the better. If you can reduce the number of customisations at all, do so as it'll make your life easier.
Use the information in https://technet.microsoft.com to upgrade the SSP on SharePoint 2007 to the appropriate service applications in SharePoint 2010. Backup and restore the databases rather than detaching them and attaching them to the new farm. That way you have a working 2007 farm at all times that you can fall back to if required.
Create your web applications that you'll need on the 2010 farm. Create each web application with a temporary database and do not create any site collections. You can then detach these temporary databases and throw them away later. Note that web applications in SharePoint 2007 are in what we'd describe as 'classic mode' in SharePoint 2010 and 2013. You can create classic mode web applications in both 2010 and 2013, but for 2013 you'll need to do so using PowerShell. Claims mode web applications are the default for 2010/2013 and should ideally be used. You can perform a migration from classic to claims mode once the farm has been migrated to 2010 or to 2013.
Backup and restore your content databases to the new SQL Server and attach them to the web applications you have created on the 2010 farm. When you restore the databases, ensure that the farm account for the 2010 farm is he DB owner before attaching them to the web applications. Use the Mount-SPContentDatabase command to attach the databases to the web applications. See https://technet.microsoft.com for details of this command. Attaching a 2007 content database to a 2010 web application upgrades the database to the new version.
If you created the 2010 farm on the new domain, this is the time to migrate the user accounts. Use the Move-SPUser command to map each account from the old domain to the new domain. See Move-SPUser for details of this command. Note that one of the examples at the bottom of the page shows migrating a user from one domain to another. If you build the 2010 farm on the old domain, all of your user information will migrate over just fine, but your 2013 farm will have to be on the new domain, whatever happens, and you'd have to perform the Move-SPUser steps at the point you migrate to 2013 instead.
Test the 2010 farm. This step is critical. Upgrading a farm never resolves issues, and can make them significantly worse in some scenarios, so it's important to test your 2010 farm at this stage and take any remedial action that's required to solve the issues. Note down everything you do to build the new farm, migrate the service application data and the content, and any steps taken to fix the issues as you may well have to perform these steps several times before you get it all 100% correct. It's also worth timing the upgrade process so that you have an idea of how long it should take when you perform the final migration.
Once the 2010 farm is done, it's time to move on to migrating to the 2013 farm.
As before start by preparing the 2010 farm. Remove any further customisations that you can, and ensure that all pages are in 2010 mode (so upgrade the look and feel of all site collections before proceeding).
Essentially the steps are the same as above, however you're now migrating from service applications to service applications rather than SSP to service applications, which should make life easier.
Build your 2013 farm on the new domain. See https://technet.microsoft.com for details on migrating from 2010 to 2013. The steps involved are:
- Migrate the service application databases, then build the service
applications using PowerShell. This allows you to specify the
database names, and reuse the existing 2010 database to create the
service applications. When creating a service application, if an
existing 2010 database is specified as the database name, it'll be
upgraded as part of the process.
- Create the web applications. See the note above regarding classic
mode vs claims mode.
- Migrate the content databases. As before, attaching them to a 2012
web application will upgrade them.
- If your 2010 farm was on the old domain, now is the time to perform
the Move-SPUser steps.
- Upgrade the web application to claims mode if required at this point.
- Test the upgrade.
As for the 2007 -> 2010 migration, document all of the steps taken so you can repeat the process and make any required corrections.
Once you have the migration process sorted, perform the final migration. This involves making the 2007 databases read-only so that no changes can be made during the migration process, then follow your documentation to perform the migration to 2010, then to 2013. As you've done this several times, have the PowerShell you've used previously, and have corrected all of the issues found during testing, this should hopefully be a smooth process.
Change any required DNS entries and inform your users that the new system is live!
